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Abstract 

C-h-Ox is the working title for the revision of the ISO standard of the 
C++ programming language that was originally planned for release in 2009 
but that was delayed to 201 1. The largest language extension in C++0x was 
"concepts", that is, a collection of features for constraining template param- 
eters. In September of 2008, the C++ standards committee voted the con- 
cepts extension into C++0x, but then in July of 2009, the committee voted 
the concepts extension back out of C++0x. 

This article is my account of the technical challenges and debates within 
the "concepts" effort in the years 2003 to 2009. To provide some back- 
ground, the article also describes the design space for constrained parametric 
polymorphism, or what is colloquially know as constrained generics. While 
this article is meant to be generally accessible, the writing is aimed toward 
readers with background in functional programming and programming lan- 
guage theory. This article grew out of a lecture at the Spring School on 
Generic and Indexed Programming at the University of Oxford, March 2010. 



1 Introduction 

The inclusion of the Standard Template Library (STL) ll8~7l into C++ in 1994 trans- 
formed the development of software libraries in C++. Before 1994, C++ library de- 
velopers primarily applied object-oriented techniques to facilitate software reuse. 
Beginning in 1994, library developers began to use the methodology of generic 
programming, which was created by Alexander Stepanov, David Musser, and col- 
leagues in the 1980s [|45l l48l l63l l64l . Generic programming is a methodology 
for decoupling algorithms from the data structures on which they operate, thereby 
enabling the use of a single algorithm implementation with many different data 



structures. Section 1.2 of this article gives a brief overview of generic program- 



ming and Section [2] goes into depth regarding how generic programming is ac- 
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complished in C++. Many software methodologies claim to be "silver bullets". 
Generic programming is not a silver bullet per se; developing generic libraries 
is a difficult task and requires considerable training and mathematical expertise. 
However, generic programming can provide significant cost savings in the long 
run. 

Generic programming, as realized in C++, relies heavily on the the template 
language feature to provide type parameterization of functions and classes. As 
programmers applied generic programming to larger and more complex libraries 
in the late 1990s and early 2000s, both the developers and users of these libraries 
began to suffer from several shortcomings of C++ templates. 

• Minor errors in the use of template libraries produced extraordinarily long 
and complex error messages. 

• Library developers could not easily check that their library code adhered to 
its specification. 

• The run-time behavior of libraries could differ in unexpected ways based on 
usage context because of non-modular rules for name resolution. 

• Applications using C++ template libraries suffered long compilation times. 

In 2003, two groups, one at Indiana University and the other at Texas A&M 
University, set out to solve these problems through the addition of language fea- 
tures for constraining template parameters. The work by these two groups ulti- 
mately led to a language extension that was voted into the working draft of the 
C++ standard on September 2008. However, in July of 2009, the standards com- 
mittee voted to remove the language extension. 

The aim of this article is to describe the technical challenges and debates 
within the "concepts" effort from 2003 to 2009 and to provide the background for 
understanding the design trade offs. The remainder of this introduction starts with 
an introduction to generic programming methodology and then gives an overview 
of the history of language support for generic programming. 

1.1 Higher-Order Polymorphic Programming 

Generic programming builds on the style of higher-order, polymorphic program- 
ming that was developed in LISP [1571 in the 1960s and that was crystallized in 
type systems of the 1970s such as System F of Girard 11301 and Reynolds ll72l and 
the Hindley-Milner [61 J type system of Standard ML [|62l . A canonical example 
of higher-order, polymorphic programming is the foldl function, shown below and 
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written in ML. The first argument to fold I is a binary function, the second argu- 
ment can be thought of as a running total, and the third argument is a list. The foldl 
function applies the binary function to each element of the list and the running 
total. The two equations below that define foldl match on the third argument, with 
nil matching the empty list and x::xs matching a non-empty list, binding x to the 
element at the front and binding xs to the rest of the list. 

fun foldl f y nil = y 

| foldl fy(x::xs) = foldl f(f (x,y)) xs 

This foldl function is quite flexible; it can compute sums, products, and many 
other things. In the first line below, we use addition as the binary function, 0.0 as 
the initial value for the running total, and [1 .0,2.0,3.0,4.0] as the list. The result of 
foldl in this case is 1 0.0, which is the sum of the integers in the list. 

> foldl op + 0.0 [1.0,2.0,3.0,4.0]; 
val it = 10.0 : real 

> foldl op* 1 [1,2,3,4]; 
val it = 24 : int 

> foldl op @[] [[1,2],[3],[4,5,6]]; 
val it = [4,5,6,3,1,2] : int list 

The foldl function is polymorphic with respect to the element type of the list. In the 
first example, the elements are real numbers. In the second, they are integers, and 
in the third, they are lists of integers. The foldl function is higher-order because 
it takes a function as a parameter, which controls whether foldl computes the sum, 
product, or concatenation in the above examples. 

To be specific, the kind of polymorphism provided in Standard ML and in 
System F is called parametric polymorphism. This kind of polymorphism is par- 
ticularly important because it enables both modular type checking and separate 
compilation. A language provides modular type checking when 1) a call to a func- 
tion, or similarly, an instantiation of a generic, can be type checked using only its 
type and not its implementation and 2) the definition of function or generic can 
be type checked in isolation, without using any information about call sites or 
points of instantiation. Modular type checking is critical for the development of 
libraries and large software systems. Modular type checking shields the client of 
a library from the internals of the library. Dually, modular type checking provides 
library developers with an automated means to rule out large classes of bugs be- 
fore distributing the library, especially bugs regarding inconsistencies between the 
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library's specification and implementation. 

A language enables separate compilation if it is possible to produce an exe- 
cutable machine program in time proportional to the size of the source code of the 
main program only, even though the program uses many software libraries. This 
definition is somewhat indirect because the more straightforward and traditional 
definition is meaningless in the presence of just-in-time compilation. Separate 
compilation is critical to the development of large software systems, as it provides 
a means to reduce compilation times during the software development cycle. 

System F is a simple model for understanding how to ensure modular type 
checking and separate compilation in a language with parameterized types. The 
definition of System F is concise enough that we can discuss the entire language 
in a few paragraphs. The syntax of System F is minimal; it only supports two 
language features: functions and generics, both of just one parameter. 

term variables x, y, z 

type variables a, f3 

integers n 

types r ::= int | a | r — > r | V<x r 

expressions e ::= n \ x \ Xx : t. e \ e e \ Aa. e | e[r] 

The types of System F includes type variables, function types, and universal types, 
which give types to generics. The terms of System F include term variables, 
anonymous functions (the A form), function application (which is the juxtapo- 
sition of two expressions, the first should evaluate to a function and the second, 
should evaluate to its argument), anonymous generics (the A form), and the ex- 
plicit instantiation of generics (e[r]). 

The modularity of System F's type system can be seen by inspecting its defini- 
tion, shown in Figure [TJ The horizontal bars should be read as if-then statements. 
The statements above the bar are premises and the statement below the bar is 
the conclusion. We use T to denote an environment, which is a sequence of the 
in-scope term variables (with their type bindings) and type variables. The type 
system disallows duplicate type variables in environments. We write x : r G T to 
mean that the first binding for x in T is r. More formally, x : r G T if and only 
if Ti = x : t for some i such that there is no j < i where Tj = x : r' for some 
t'. The notation Their means that e is well typed and has type r in the scope 
defined by T. The notation [a:—r']r is for the capture-avoiding substitution of r' 
for a in r. 

To see the modularity of the type system, first look at the rule for function ap- 
plication, with the conclusion r h e± ei : r'. This rule requires that the parameter 
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x : r G T 



r h n : int T \- x : r 

r,i:rhe:T' r h e x : r ->■ r' T h e 2 : r 

T h Ax:r. e : r — )> r' r h ei e 2 : t' 

T,ahe:r g^T The: Vq. r 

rhAa.e:V«.r ~ T h e[r'] : [a:=r']r 

Figure 1: The typing rules for System F. 

type r of the function e 1 is the same type as the type of e 2 . Note that this rule does 
not require any knowledge of the body of the function being applied, just its type 
t — > t' . Similarly, look at the rule for instantiating generics, with the conclusion 
T h e[r'] : [a:=r']r. Again, the rule does not require any knowledge of the body 
of the generic. Instead, it just requires knowledge of the generic's type. 

On the flip side, consider the typing rules for creating functions and generics. 
A function knows that its input x has type r, but it has no information about what 
value will be bound to x. Analogously, a generic knows that its parameter a is 
a type, but it does not know which type will be bound to a. The type system 
ensures that a well-typed generic does not depend on which type is bound to a, 
that is, it ensures that the generic will work with any choice for a. The way the 
type system ensures this is that it considers a different from every other type. (So 
a is only equal to itself.) This property of the type system comes from its use 
of syntactic identity to check whether two types are equal. Consider the rule for 
function application: the parameter type r has to be syntactically identical to the 
type of the argument e 2 . For example, the following term is not well typed (after 
adding support for integers to System F). 

Aa. \x:a^ra. (x 1) 

In the application (x 1), the parameter type is a but the argument type is int. 
From the preceding discussion, we see that System F provides both polymorphism 
and modular type checking: an instantiation of a generic can be type checked 
without referring to the generic's body and the body of a generic can be type 
checked without referring to any instantiations. 

Furthermore, the design of System F enables separate compilation but does 
not require it. The run-time behavior of the body of a generic may not depend 
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on the instantiating type. Thus, it is possible to emit machine code that works 
for all instantiations of the same generic, modulo some restrictions on the calling 
conventions. In particular, the calling convention for data associated with a type 
parameter must be uniform, that is, it cannot depend on the instantiating type. 
The most common uniform representation is "boxing", that is, storing data on 
the heap and referring to it through a pointer. The compiler for a programming 
language with parametric polymorphism may choose to support separate compi- 
lation and use boxing, such as Java Q and Objective Caml ll54l . or it may choose 
not to for the sake of efficiency, such as the MLton lfT5ll compiler for Standard 
ML [62J. Better yet, a compiler may support separate compilation in general but 
sometimes optimize the instantiation of a generic when the body of the generic is 
available 02. 

1.2 Generic Programming 

Generic programming is a methodology that builds upon higher-order, polymor- 
phic programming, scaling it up to deal with large families of algorithms and data 
structures. For example, the STL includes a function named accumulate that gen- 
eralizes foldl to work on any representation of a sequence, not just linked lists. 
Going further, the STL includes a comprehensive set of sorting and searching 
functions. Beyond the STL, programmers applied generic programming in the 
development of libraries in the areas of computational geometry @, quantum me- 
chanics 0, graph algorithms (the author's Boost Graph Library [84J), and many 

more EH ED EDGE). 

The main programming language capability that is needed for higher-order, 
polymorphic programming to scale to large software libraries is the capability to 
organize and group together parameters, such as the parameters f and y of foldl. 
The number of such parameters grows large for interesting algorithms, upwards 
of 20 parameters! The key to organizing these parameters is that there are relation- 
ships between subgroups of parameters, and that these relationships form coherent 
abstractions. For example, in the use of foldl with multiplication, the choice of 1 
as the argument to parameter y was not by chance. The integer 1 is the identity 
element for multiplication, that is, for any integer x, 1 * x = x. (Imagine using 
for y instead. The result of foldl would be uninteresting.) 

Mathematicians have been discovering such abstractions for quite some time, 
defining algebraic structures to describe these abstractions and proving reusable 
theorems about these abstractions HIOOII . An algebraic structure consists of: one 
or more sorts, signatures for operations over the sorts, and axioms that describe 
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the semantics of the operations. For example, the algebraic structure that matches 
the needs of foldl is Monoid. A Monoid consists of a sort S together with a bi- 
nary operation on S that is associative and that has an identity element in S. An 
instance of an algebraic structure is a set for each sort, and an operation for each 
signature, such that the axioms are true. The set of integers with addition and is 
an instance of Monoid. 

In the late 1970s and early 1980s, Burstall and Goguen OH El and Kapur, 
Musser, and Stepanov ll45l noticed that it is helpful to think of computer algo- 
rithms as operating on algebraic structures instead of concrete data structures. To 
quote Stepanov: 

That is the fundamental point: algorithms are defined on algebraic 
structures K7^ . 

In this setting, algebraic structures are analogous to interfaces (as in Java) and 
instances are analogous classes that implement the interfaces. 

However, the analogy between algebraic structures and interfaces is superficial 
because they differ both with regards to both purpose and semantics. Interfaces 
are primarily created to categorize classes whereas algebraic structures are cre- 
ated to express the requirements of theorems (in mathematics) and algorithms (in 
computer science). With respect to semantics, a class may inherit from an inter- 
face if it provides methods that satisfy the variance rules required by subtyping 
(contravariant parameter types and covariant return types). On the other hand, a 
class implements an algebraic data structure if substituting the class for the struc- 
ture's sort in the structure's operation signatures yields a set of signatures that are 
implemented by the class. This subtle difference is significant: interfaces suffer 
from the binary method problem whereas algebraic structures do not (8]|. 

The late 1970s and 1980s saw considerable developments both in the prac- 
tice of generic programming and in the design of language features that sup- 
port generic programming. Kershenbaum, Musser, and Stepanov ll48l devel- 
oped generic sorting and searching algorithms in Scheme and then Musser and 
Stepanov Il64l developed similar algorithms in Ada. Recall that Scheme is a dy- 
namically typed language, so it is straightforward to express polymorphic algo- 
rithms in Scheme. Ada, on the other hand, was one of the early statically typed 
languages to support parametric polymorphism. However, neither Scheme or Ada 
provided support for organizing parameters of generic algorithms. (This support 
was added to Ada later, in 1995, with the addition of generic package parameters.) 
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create semigroup(S : set, +: SxS — > S) 
with x + (y + z) = (x + y) + z; 



create monoid(S : semigroup, 0: () ->■ S) 
with + x = x + = x; 

create sequence(S : set, E : set, isnull : S -> bool, head : S -> E, tail : S -> S); 

provide sequence of monoid with 
reduction: 

x — Hf isnull(x) then else head(x) + reduction(tail(x)) 

integers(l : set, + : I x I ->• I, * : I x I ->• I, : () ->• 1, 1 : () ->• I) 

instantiate monoid of integers (S=l, + = +,0 = 0) 
instantiate monoid of integers (S=l, + = *, = 1) 

Figure 2: A generic reduction function written in Tecton. 

1.3 Programming Language Support for Generic Programming 

There were several lines of research in the 1980s to support the specification and 
use of algebraic structures in programming. Burstall and Goguen [|T0l [TTJ and 
Kapur et al. [46 1 developed the specification languages CLEAR and Tecton, re- 
spectively. An example of defining some algebraic structures and using them in 
a generic reduction function (a generalization of foldl), is shown in Figure [2| writ- 
ten in Tecton. Burstall collaborated with MacQueen on the HOPE language lfT2l . 
which in turn inspired MacQueen's work on the signatures and functors of the 
Standard ML module system Il56ll . In the field of computer algebra, Jenks and 
Trager [|40l created the Scratchpad language. Liskov et al. 11551 , while not explic- 
itly targeting algebraic structures, did include a feature called type set in CLU that 
could be used to express algebraic structures. CLU was meant to support abstract 
data types, but it turns out that abstract data types and algebraic structures are 
closely related. 

By the 1980s, object-oriented languages were gaining momentum, and work 
was underway to integrate parametric polymorphism into object-oriented lan- 
guages. Cardelli and Wegner [14] developed bounded polymorphism, that is, 
using subtyping to express constraints on type parameters. Canning et al. ITT3TI 
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generalized bounded polymorphism to enable recursive bounds, which laid the 
foundation for generics in Java [7 J and C# ll47l 110411 . 

In 1988, Stroustrup [90] added support for generic programming to C++ with 
the addition of templates. Stroustrup considered using bounded polymorphism, 
but it was not a natural fit for many of the use cases he had in mind [|92ll . Stepanov 
suggested using a design similar to Ada's generic packages, with explicit in- 
stantiation, but Stroustrup disagreed with such a design because he thought ex- 
plicit instantiation would be an unreasonable burden on clients of a generic li- 
braries ll88ll9Tll93l . Stroustrup also looked at the design choices in ML [89|, but 
he did not model C++ templates after ML's functors for the same reason: functors 
required explicit instantiation. However, some confluence in the two designs can 
be seen in C++'s template argument deduction for function templates. The algo- 
rithm is based on the mathematical notion of matching, which is the single-sided 
version of the unification algorithm at the heart of Hindley-Milner type inference. 

Templates were designed to be safer than C preprocessor macros but just as 
efficient [|90l . Macros had been used for years as "a poor man's generics". The 
design for type checking templates followed a similar model to that of macros: 
type checking occurs after instantiation. (For templates, some checking happens 
before instantiation, but not much.) This design choice had some significant ad- 
vantages and disadvantages. The primary advantages were extreme flexibility and 
expressiveness: it opened the door to template metaprogramming HI [3j I101H . 
The primary disadvantage was the lack of modular type checking. We discuss 
the semantics and type system for templates in more detail in Section [2} The 
flexibility of templates, combined with function overloading, provided a means 
to write type-parameterized functions and to implicitly parameterize over opera- 
tions, thereby making it relatively convenient to write generic algorithms in C++. 
In concert with Stroustrup's work on templates, Stepanov began developing a C++ 
component library ll8~6l along the lines of his prior work in Scheme and Ada. This 
C++ library was the direct precursor to the Standard Template Library. 

The 1980s ended with an important result: Kaes [|44l and Wadler and Blott 
H102H discovered parametric overloading, then Wadler and Blott HI 0211 expanded 
the idea to create the type class feature for Haskell. Type classes were not explic- 
itly designed to support algebraic structures. Instead they were a generalization 
of ML's equality types. Nevertheless, type classes provide excellent support for 
generic programming, combining a modular type system with the convenience of 
implicit instantiation of generics (in contrast to the explicit functor application of 
Standard ML). If only the divide between the imperative and functional program- 
ming communities had not been so large! 
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1.4 Road Map 

In the next section we briefly survey the style of generic programming that is used 
to develop modern C++ template libraries, as concepts are meant to support this 
style of programming. After that, we discuss the preliminary language design 
work at Texas and Indiana (Section [3]). We then take a look at the two proposals 
to the C++ standards committee, first the Indiana proposal (Section [4]) and then 
the Texas rebuttal (Section [5]). The two teams formed a compromise at the Adobe 
meeting (Section [6]) which lead to the final design for concepts that was voted 
into the C++ standard working draft (Section [7]). Unfortunately, the compromise 
unraveled and concepts were voted back out of C++ (Section [8]), leaving much in 
doubt regarding the future of concepts in C++ (Section [9]). 

2 Generic Programming and C++ Templates 

In this section we take a closer look at the modern practice of generic program- 
ming in C++. The examples are from the Standard Template Library [87J, though 
they could have easily come from many other generic libraries. The presentation 
here is in the style of the SGI version of the STL 01. 

In the parlance of modern C++, concept means algebraic structure and model 
means an instance of an algebraic structure [4, 88]. The shift away from using 
the term "algebraic structure" makes sense because many of the abstractions have 
little to do with algebra. Also, the term "structure" is too close to struct, which 
has a very different meaning in C++. Unfortunately, the term "concept" is rather 
generic. 



Algorithms Iterator Concepts Containers 




Figure 3: Organization of the Standard Template Library. 
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Figure [3] depicts the organization of the Standard Template Library. The STL 
contains 112 generic algorithms and 12 container classes. More importantly, the 
STL provides a handful of iterator concepts that decouple the algorithms from the 
containers. Because of the iterator abstractions, there only needs to be 112 algo- 
rithm implementations and 12 iterator implementations to enable the algorithms 
to work with all of the containers. (At least, for all the combinations that makes 
sense.) Using traditional procedural or object-oriented techniques, there would 
be 112 x 12 algorithm implementations, as each algorithm is implemented by 
different code for each container class. 

Figure [4] depicts the hierarchy of iterator concepts within the STL. The ar- 
rows indicate the refinement relation between concepts (analogous to inheritance 
between interfaces). A concept refines another concept if it includes all of the 
capabilities of the other concept. Or put another way, concept C\ refines Ci if 
all the models of C\ are also models of Ci- The Random Access Iterator concept 
requires the most capabilities, in particular it requires the capability of jumping 
forward or backwards an arbitrary number of positions in constant time. The In- 
put and Output Iterator concepts require the least capabilities, just requiring the 
ability to make a single pass through a sequence, respectively reading or writing 
to the elements. 



Input 



Random Access 



Bidirectional 



Forward 



Output 



Figure 4: The Iterator Concepts of the Standard Template Library. 



The iterator hierarchy provides a fine-grained categorization of iterator capa- 
bilities to enable each algorithm to precisely specify its requirements. The preci- 
sion is necessary to maximize reusability: each algorithm should use the minimal 
requirements necessary to efficiently carry out its task, thereby maximizing the 
number of situations in which it can be used. An important point to stress is 
that, in generic programming, the raison d'etre for concepts is to provide con- 
cise means for algorithms to specify their requirements. This viewpoint contrasts 
with object-oriented methodologies in which interfaces are created to categorize 
classes independently of their use in algorithms. 

Figure [5] shows the description of the Input Iterator concept from the SGI 
STL [4J. In the description, the type variable X is used as a place holder for the 
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Description 

An input iterator provides the capability of traversing through a sequence once 
and reading the values of the elements. 

Associated Types 

• iterator_traits<X>::value_type, this is the element type of the sequence. 

• iterator_traits<X>::difference_type, this is for measuring distances between 
positions in the sequence. 



Valid Expressions 

(X is the iterator type, T is the value type) 



expression 


return type 


semantics 


*i 


Convertible to T 


Returns the value at position i 


++i 


X& 


Moves the iterator to the next posi- 
tion. 


i ==j 


bool 


Returns true if i and j are at the same 
position, i == j implies *i == *j 


i!=j 


bool 


Equivalent to !(i == j). 



Complexity guarantees 

All operations are amortized constant time. 



Figure 5: The Input Iterator Concept 

modeling type. The valid expressions specify the operations that must be provided 
by the modeling type. The complexity guarantees enable generic algorithms to in 
turn state guarantees regarding their execution time. Associated types are types 
that have an auxiliary role in the concept and whose identity depends on (is a 
function of) the modeling type. (Associated types are related to virtual types [|9l 
1251 l67l 1991 , but avoid many of the difficulties by being accessed through types 
instead of objects. Associated types are most closely related to abstract types of a 
signature in ML.) In C++, associated types are usually accessed through a template 
trick known as traits [|65l . 

Figure [6] lists the merge function template from the STL, which serves here 
as a typical example of a generic algorithm. The documentation for merge states 
that the type parameters Inlterl and Inlter2 must model Input Iterator. The need for 
this requirement can be seen in that the algorithm increments, dereferences, and 
uses the not-equal operator on the the iterators firstl , lastl , first2, and Iast2. The 
Outlter type is required to model Output Iterator, which enables the dereference 
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template <typename Inlterl , typename Inlter2, typename Outlter> 
Outlter 

merge(lnlter1 first"!, Inlterl lastl, Inlter2 first2, Inlter2 Iast2, Outlter result) { 
while (firstl != lastl && first2 != Iast2) { 
if (*first2 < *first1) { 
*result = *first2; 
++first2; 
} else { 
*result = *first1 ; 
++first1 ; 

} 

++result; 

} 

return copy(first2, Iast2, copy(first1, lastl, result)); 

} 

Figure 6: The Merge Function Template of the STL. 

and assignment to result as well as the incrementing of result. Also, to enable 
the assignment, the value type of Outlter must be the same as the value types 
of Inlterl and Inlter2. And finally, the if-statement compares the elements of the 
two input iterators, so the associated value type of Inlterl must model the Less 
Than Comparable concept. The merge function calls the copy function template, 
which is also part of the STL. The copy template in turn places requirements on 
its type parameters, and those requirements are a subset of the type requirements 
for merge. 

2.1 The Semantics of C++ Templates 

The main idea behind the semantics of templates is that different versions of a 
template are stamped out for different uses. The min function template and its use 
in main in Figure [7J serves to demonstrate the key ideas. At the point where min 
is defined, a C++ type checker looks at any expressions in the body of min whose 
type does not depend on the type parameters. In this case, there are none, so no 
type checking occurs at the point of definition of min. 

Moving on to the main function, the call to std::min is an example of template 
argument deduction. A C++ compiler deduces that int should be chosen for pa- 
rameter T by pattern matching the argument types against the parameter types. So 
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namespace std { 
template <class T> 
Tmin(T a, T b) { 
if (b < a) return b; else return a; 

} 

} 

int main() { 
return std::min(3, 4); 

} 

Figure 7: A simple function template: the min operation. 

the compiler transforms the call to include an explicit instantiation: 

int main() { 
return std::min<int>(3, 4); 

} 

A C++ compiler then generates a version of std::min that is specialized for int. The 
following is a source code representation of the generated code (which usually 
only exists in the internal representation of the compiler). 

namespace std { 
templateo 

int min<int>(int a, int b) { 
if (b < a) return b; else return a; 

} 

} 

A C++ compiler type checks the specialized code, which in this case is well typed. 
If we change the example to apply min to a type that does not provide a less-than 
comparison operator, as follows, 

struct A {}; 
int main() { 
A a; 

return std::min(a, a); 

} 

we get an error message that points inside the min function template. 

errorl .cpp: In function T std::min(T, T) [with T = A]': 
errorl .cpp:8: instantiated from here 
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errorl .cpp:3: error: no match for 'operator^ in 'b < a' 

For such a small template, this error is not difficult to debug, but for most tem- 
plates in the STL, such errors are infamously difficult to comprehend. For ex- 
ample, the following program that mistakenly applies stable_sort to a linked list 
results in the error message in Figure [8} Can you see the problem? 

int main() { 
list<int> I; 

stable_sort(l.begin(), l.end()); 

} 

The stable_sort template requires the iterators to provide random access, but the 
iterators of a double linked list are merely bidirectional. 

These examples demonstrate that C++ does not have a modular type system. 
When checking the use of a template, the C++ type checker looks at the body of 
the template. To be modular, C++ would need the notion of the type of a template, 
like the universal type of System F, and it would have to check uses of templates 
against such types, but it does not. 

As more programmers began to use the STL in the late 1990s and early 2000s, 
such error messages became a constant aggravation and deterred many program- 
mers from using the STL. Meyers |58|, an author of many popular C++ books, 
writes 

Perhaps most daunting, even the smallest STL usage error often led 
to a blizzard of compiler diagnostics, each thousands of characters 
long, most referring to classes, functions, or templates not mentioned 
in the offending source code, almost all incomprehensible. 

Building on an idea of Stepanov's, I developed a C++ library to check require- 
ments on type parameters and thereby improve the error messages [1791 . However, 
using the library required writing tedious and error prone code, and the quality of 
the error messages was dependent on the compiler. 

2.2 Templates and Separate Compilation 

The specialization-based semantics of C++ templates rules out the possibility of 
separate compilation. Other languages, such as ML and Java provide generics 
but retain separate compilation, so why can't C++? It turns out that not only is 
specialization the main implementation approach for compiling templates, but the 
semantics of the language forces it to be the only implementation approach. 
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stl_algo.h: In function Void std:: inplace_stable_sort(_RandomAccesslterator, _RandomAccess Iterator) 

[with _Random Access Iterator = std::_List_iterator<int>]': 
stl_algo.h:3633: instantiated from Void std::stable_sort(_RandomAccesslterator, _RandomAccesslterator) 

[with _Random Access Iterator = std::_List_iterator<int>]' 
errorl .cpp:8: instantiated from here 

stl_algo.h:2921 : error: no match for 'operator' in ' last first' 

stl_algo.h:3633: instantiated from Void std::stable_sort(_RandomAccesslterator, _RandomAccesslterator) 

[with _Random Access Iterator = std::_List_iterator<int>]' 
errorl .cpp:8: instantiated from here 

stl_algo.h:2926: error: no match for 'operator' in ' last first* 

stl_algo.h:2929: error: no match for 'operator' in ' middle first 1 

stl_algo.h:2929: error: no match for 'operator' in ' last middle' 

stl_algo.h: In function Void std:: stable_sort_adaptive(_RandomAccesslterator, _RandomAccesslterator, _Pointer, _Distance) 

[with _Random Access Iterator = std::_List_iterator<int>, _Pointer = int*, _Distance = int]': 
stl_algo.h:3635: instantiated from Void std::stable_sort(_RandomAccesslterator, _RandomAccesslterator) 

[with _Random Access Iterator = std::_List_iterator<int>]' 
errorl .cpp:8: instantiated from here 

stl_algo.h:3550: error: no match for 'operator' in ' last first' 

stl_algo.h:3551 : error: no match for 'operator+' in ' first + len' 

stl_algo.h:3635: instantiated from Void std::stable_sort(_RandomAccesslterator, _RandomAccesslterator) 

[with _Random Access Iterator = std::_List_iterator<int>]' 
errorl ,cpp:8: instantiated from here 

stl_algo.h:3564: error: no match for 'operator' in ' middle first' 

stl_algo.h:3564: error: no match for 'operator' in ' last middle' 

stl_algo.h: In function Void std:: insertion_sort(_RandomAccesslterator, _RandomAccesslterator) 

[with _Random Access Iterator = std::_List_iterator<int>]': 
stl_algo.h:2923: instantiated from Void std:: inplace_stable_sort(_RandomAccesslterator, _RandomAccesslterator) 

[with _RandomAccesslterator = std::_List_iterator<int>]' 
stl_algo.h:3633: instantiated from Void std::stable_sort(_RandomAccesslterator, _RandomAccesslterator) 

[with _Random Access Iterator = std::_List_iterator<int>]' 
errorl ,cpp:8: instantiated from here 



Figure 8: The prefix of a typical error message that arises from misusing the STL. 



One might think that a C++ compiler could support both separate compilation 
and specialization by postponing template specialization to run time. However, 
the reader may recall that the definition of separate compilation (Section [TTT] ) re- 
quires that the amount of time used for compilation (whether it be at compile time 
or run time) be proportional to the size of the application, not including the size of 
the (template) libraries that it uses. Thus, even an implementation using run-time 
specialization would not provide separate compilation. 

There are several language features in C++ that force specialization; the one 
we describe here is user-defined template specialization. The example in Figure [9] 
demonstrates that many phases of a C++ compiler, from front-end type checking to 
back-end code generation, require specialization. The example shows a function 
template f that refers to class template C, using its nested type num to declare an ar- 
ray A. The call f('z') causes C to be instantiated with the type argument char, which 
results in the user-defined specialization of C and the typedef of num to int. So 
sizeof(U) is 4 bytes (assuming a 32 bit architecture) and therefore sizeof(U)/4 — 1 
is zero, causing x to be assigned to the first element of the array. The call f(42) 
causes C to be instantiated with int, which results in the instantiation of the pri- 
mary template and the typedef of num to double. So sizeof(U) is 8 bytes and 
therefore sizeof(U)/4 - 1 is one, causing x to be assigned to the second element of 
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template<typename T> 
struct C { 
typedef double num; 

}; 

templateo 
struct C<char> { 
typedef int num; 

}; 

template<typename T> 
void f(T x) { 

typedef typename C<T>::num U; 

U A[2]; 

A[sizeof(U)/4 - 1] = x; 

} 

int main() { 

f('z'); 

f(42); 

f(pair(1,2)); 

} 

Figure 9: User-defined specialization inhibits separate compilation. 
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the array. The call f(pair(1 ,2)) results in a type error because pair is not convertible 
to double. 

This example shows that C++ templates are not a form of parametric polymor- 
phism (as technically defined) because the behavior of a template may depend 
on its type arguments. But more importantly, it shows that compilation time is a 
function of the number of template instantiations. For example, the type checking 
of f's body must be repeated for each unique instantiation because there can be a 
different outcome for each one: f(42) was well typed but not f(pair(1 ,2)). Further- 
more, the generated assembly code for the instantiations of f would need to differ 
in many ways. For example, most architectures provide different instructions for 
storing int versus double, so the assignment of x into A would require different 
instructions. Thus, in general, a C++ compiler needs to generate different code 
sequences for different instantiations. 

So the compilation time for a C++ application must be a function of the size 
of all the templates libraries it uses, transitively. For modern C++ applications, the 
compilation time can stretch from minutes into hours. 

2.3 Templates and Name Lookup 

While non-modular error messages are the most obvious problem with the se- 
mantics of C++ templates, there are also subtle problems regarding name lookup. 
Consider the min template again, but this time we apply it to a user-defined type 
that provides a less-than operator. 

namespace L { 
class interval { }; 

bool operator<(interval x, interval y) { ... } 

} 

int main() { 
L::interval i, j, k; 
k = std::min(i,j); 

} 

The above example is well typed, but how? How does the use of the less-than 
operator inside std::min resolve to the less-than operator in namespace L? The an- 
swer is argument dependent name lookup (ADL). When a C++ compiler performs 
name lookup for the function name in a function call, it not only considers the 
names that are in lexical scope but it also analyzes the argument types and then 
includes all the names in the namespaces in which those types were defined. In 
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namespace lib { 

template <class T> void load(T, string) { printf ("Proceeding as normal !\n"); } 
template<class T> void initialized x) { load(x, "file"); } 

} 

namespace N { 
struct b { int n; }; 

template <class T> void load(T, const char*) { printf("Hijacked!\n"); } 
template<class T> void shoot(T x) { load(x, "ammunition"); } 

} 

int main() { 
N::ba; 

lib::initialize(a); 

} 

//Output: Hijacked! 



Figure 10: Argument dependent lookup can lead to unintended run-time behavior. 



this case, the less-than operator is applied to arguments of type interval, and interval 
was defined in namespace L. So the less-than operator in namespace L is among 
the entities returned by name lookup in this case. 

While argument dependent name lookup may seem like a good thing, it is not 
modular and causes bugs when building large software systems. The example in 
Figure [10] is distilled from a real bug that showed up in an application using the 
Boost C++ libraries. The initialize function template in namespace lib intends to 
call another function template in lib named load. Unbeknownst to the author of lib, 
there is another function named load in namespace N that is meant to be a helper 
function for shoot. Because of argument dependent lookup, the call to load inside 
of initialize does not resolve to lib::load, but instead resolves to N::load. Thus, the 
output of the above program is "Hijacked!". What is particularly troubling about 
this example is that the run-time behavior of lib: initialize depends on the context 
in which it is used, analogous to the infamous dynamic scoping of Lisp ll43l . 



2.4 Tag Dispatching 

On the positive side, the semantics of C++ templates enables some powerful pro- 
gramming styles. For example, there is a natural tension between performance 
and generality in algorithm design. Often times there exist multiple algorithms to 
solve the same problem, where one algorithm is more efficient than another, but 
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template <class Inlter, class Dist> 
void advance_aux( In lter& i, Dist n, input_iterator_tag) 
{ while (n) ++i; } 

template <class Randlter, class Dist> 

void advance_aux(Randlter& i, Dist n, random_access_iterator_tag) 
{i+=n;} 

template <class Inlter, class Dist> 
void advance(lnlter& i, Dist n) { 

typename iterator_traits<lnlter>::iterator_category cat; 

advance_aux(i, n, cat); 

} 

Figure 1 1 : An example of the tag dispatching idiom. 



requires more capabilities from the types it operates on. The advance function of 
the STL is a particularly simple example of this. The advance function moves an 
iterator forward n positions within the sequence. If the iterator models Random 
Access Iterator, then the iterator can directly jump forward n positions in constant 
time. On the other hand, if an iterator only models Input Iterator, then it takes 
linear time to move forward n positions. 

An obvious solution to this problem is to have two differently named functions 
for advancing iterators. However, what if the need to advance iterators appears in 
the context of a generic algorithm? For example, the lower_bound function tem- 
plate of the STL calls advance, but is itself parameterized on the iterator types. In 
that context we do not know which iterators are being used. The solution to this 



problem in C++ is the tag dispatching idiom, shown in Figure 1 1 We create a sin- 
gle entry point named advance and then use traits to inquire about the capability 
of the iterator. The resulting tag is used to influence the function overload resolu- 
tion for the call to the helper functions named advance_aux. The tag dispatching 
trick works because the overload resolution of the call to advance_aux inside of 
advance does not occur until after advance has been instantiated on particular con- 
crete iterator types. 

'Kiselyov and Peyton- Jones [50] describe a solution to this problem in Haskell. 
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2.5 Evaluation of C++ Templates 



To briefly evaluate the design of C++ templates, on the positive side C++ effec- 
tively enables generic programming by providing type parameterization and the 
convenient use of function templates through template argument deduction and 
argument dependent lookup. Furthermore, the run-time performance of C++ tem- 
plates can match that of hand-coded procedures because the specialization ap- 
proach leaves behind little or no run-time overhead. Last but not least, the lack of 
point-of-definition type checking for templates provided the flexibility needed for 
template metaprogramming. 

On the negative side, the type checking of templates is not modular which 
leads to confusing error messages for users of generic libraries and opens the door 
to discrepancies between a library's documentation and implementation. Fur- 
ther, because argument dependent lookup is non-modular, the run-time behavior 
of template libraries can silently change in unexpected ways in different usage 
scenarios. Finally, the specialization semantics of C++ templates prevents sepa- 
rate compilation, so developers of large C++ applications endure long compilation 
times. 



3 Preliminary Research on Concepts 

In 2003, two teams set out to design an extension to C++ to improve C++ templates 
by providing modular type checking. To type check the body of a template inde- 
pendently of any instantiation, the type checker needs to know what assumptions 
are being made about the type parameters. As discussed in the previous section, 
these assumptions were commonly stated in the documentation for the template; 
what was needed was a way to make these assumptions explicit in the code. The 
two teams set out to add support for type constraints, using concepts to express 
the constraints. At Texas A&M University, Bjarne Stroustrup (having just moved 
from AT&T Labs-Research) and then post-doc Gabriel Dos Reis began the Pivot 
project and produced several technical reports for the C++ standards committee. 



We discuss these reports in Section 3.3 



At Indiana University, Professor Andrew Lumsdaine, post-doc Jaakko Jarvi, 
and the graduate students Ronald Garcia, Jeremiah Willcock, and I also began 
working on concepts and constrained generics. We did not have prior experi- 
ence in language design, but we had considerable experience in the design and 
implementation of generic libraries [|27j E7J [38l E21 |77J UE ED- Our first ma- 
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* Using the multi -parameter type class extension to Haskell. 

Table 1: Results from the study of language support for generic programming. 
A black circle indicates full support, a white circle indicates poor support, and 
a half-filled circle indicates partial support. The rating of "-" in the C++- column 
indicates that C++ does not explicitly support the feature, but one can still program 
as if the feature were supported due to the permissiveness of C++ templates. 

jor undertaking was to study support for generic programming in state of the art 
programming languages, discussed in the following section. 

3.1 Indiana: A Comparative Study 

In our study ll28l we implemented several generic algorithms from the Boost 
Graph Library ll84l in six languages: C++, Standard ML, Haskell, Eiffel, Java, 
and C#. (In a follow-on study, we added OCaml and Cecil [29 1.) We sought to 
use best practices for each language. In the course of the study, we took note 
of when the presence or absence of a language feature made the implementation 
more or less difficult. Table [TJ summarizes the results of the study. 

The following explains the language features that form the rows of the table. 
"Multi-type concepts" indicates whether multiple types can be simultaneously 
constrained. "Multiple constraints" indicates whether more than one constraint 
can be placed on a single type parameter. "Associated type access" rates the ease 
in which types can be mapped to other types within the context of a generic func- 
tion. "Retroactive modeling" indicates the ability to add new modeling relation- 
ships after a type has been defined. "Type aliases" indicates whether a mecha- 
nism for creating shorter names for types is provided. "Separate compilation" in- 
dicates whether generic functions are type-checked and compiled independently 
from their use. "Template arg. deduction" indicates that type arguments can be 
deduced without requiring explicit syntax for instantiation. "Concise syntax" in- 
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dicates whether the syntax required to compose layers of generic components is 
independent of the scale of composition. 

Haskell faired particularly well in this study, with Standard ML not too far 
behind, while Eiffel, Java, and C# did not do as well. The underlying pattern was 
that the three object-oriented languages relied on F-bounded polymorphism [fT3l . 
whereas Standard ML and Haskell did not. Standard ML supports generic pro- 
gramming through Functors and signatures and Haskell supports generic program- 
ming via type classes. The take-away point for us was that a design for concepts in 
C++ should be based on the best features of Haskell and Standard ML, and not F- 
bounded polymorphism. Our case study influenced other programming language 
researchers. For example, Chakravarty et al. lfT6l [T71l added associated types to 
Haskell, filling in the only half-circle for Haskell in Table [T] 

3.2 Texas: Proposal at Kona 

At the October, 2003 C++ standards committee meeting in Kona, Stroustrup and 
Dos Reis presented three technical reports, N1510 Il92ll. N1522 [|95l , andN1536 flU 
that sketched a design for concepts. 

There were five important aspects to the Texas design. First, they proposed 
usage patterns as the mechanism for specifying which operations are required of 
the modeling type, that is, the type implementing the concept. Usage patterns 
mimic the notation that had become common for documenting generic libraries. 
The following example shows a concept that requires the modeling type to provide 
a copy constructor, an addition operator, and an assignment operator. 

concept Add { 

constraints(Add x) { Add y = x; x = x+y; } 

}; 

Second, the design proposed composing concepts using the logical operators 
&& (and), || (or), and ! (not). In the following, the concepts C1 and C2 are combined 
in different ways to constrain the T type parameter of three classes. 

template <(C1 && C2) T> class X { ... }; 
template <(C1 || C2) T> class Y { ... }; 
template <(C1 && !C2) T> class Z { ... }; 

Third, the proposal did not include support for associated types, but instead 
proposed parameterized concepts. In the following Forward_iterator concept, the 
value type of the iterator is a type parameter. 
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template <Value_type V> concept Forward_iterator { 
constraints(Forward_iterator p) { 
Forward_iterator q = p; Vv = *p; p++; ++p; 

} 

} 

Fourth, the proposal included concept-based overloading. That is, extending 
the rules for function overload resolution to take into account the constraints on 
type parameters. This feature was meant to replace the tag dispatching idiom. For 
example, below are the two advance algorithms, the first requiring only an Input 
Iterator and the second requiring a Random Access Iterator. 

template <lnputlterator lnlter> 
void advance(lnlter& i, lnlter::difference_type n) 
{ while (n) ++i; } 

template <RandomAccesslterator Randlteo 
void advance(Randlter& i, Randlter::difference_type n) 
{i+=n;} 

Fifth and finally, the proposal used implicit modeling. That is, a C++ compiler 
would automatically deduce whether a class models a concept. In the following 
example, we instantiate the f function template with class A. Template f requires 
A to model the Add concept, so the C++ compiler would check that A implements 
all of the operations required by the Add concept. 

class A { }; 

A operator+(A x, A y) { ... } 

template<Add T> void f(T x) { ... } 

int main() { 
A a; 

f(a); // compiler deduces that A models Add 

} 

At the Kona meeting and in the following months, several problems with the 
proposal were identified. With respect to usage patterns, there was an open ques- 
tion regarding implementation. To type check the body of a template, the usage 
patterns would need to be converted to type signatures for use in the typing en- 
vironment (that is, the symbol table). Supposing that hurdle could be overcome, 
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there was also an issue regarding usability. For example, it seems that the follow- 
ing template h, which seems fine, would in fact be ill typed. 

template<Add T> void g(T x, T y) { ... } 

template<Add T> void h(T x, T y) { 

g(x, x + y); // error: no matching function for call to 'g(T, T1)' 

} 

To explain, the usage patterns for the Add concept, defined above, would imply 
that, given a type T that models Add, addition would have the following signature: 

T1 operator+(T,T); 

where T1 is some type convertible to T 

Thus, in the call to g, the types of the two arguments would be T and T1 , respec- 
tively. But g requires that the two arguments be of the same type. 

The third issue regarding usage patterns was that any C++ expression was al- 
lowed as a usage pattern. Together with implicit modeling and concept-based 
overloading, the C++ compiler would need the ability backtrack out of arbitrar- 
ily deep chains of template instantiations, which would require significant re- 
engineering of the industry's C++ compilers. 

With respect to composing concepts, the && operator was straightforward and 
expected, but the || and ! operators were both unexpected and problematic. They 
were unexpected because their was no use of them in the documentation of C++ 
template libraries. The || operator was problematic because it seemed that adding 
this operator would cause type checking to become exponential. The ! operator 
was problematic because its semantics was unclear: how does the type checker 
make use of such a constraint inside the body of a template? And on the instanti- 
ation side, the ! operator might require the close-world assumption and therefore 
be incompatible with separate type checking. 

With respect to parameterized concepts, the Texas design was similar to Haskell's 
type classes, which supported multi-parameter type classes but not associated 
types. However, our comparative study showed that associated types provide a 
nice mechanism for reducing the number of type parameters needed in generic 
algorithms ||28ll29Tl. 

Finally, the combination of implicit modeling and concept-based overloading 
produces some dangerous situations [32] . Consider the vector class from the STL 



shown in Figure 12 It has two constructors that accept an iterator range. The first 
only requires the iterators to model Input Iterator, so the algorithm can only make 
a single pass through the iterator range and must continually resize the vector's 
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template<typename T> 
class vector { 

templatednputlterator lnlter> vector(lnlter first, Inlter last); 
template<Forwardlterator Fwdlter> vector(Fwdlter first, Fwdlter last); 

}; 

int main() { 
istream_iterator<int> i(cin), j; 

vector<int> v(i, j); // Silently dispatches to the wrong constructor! 

} 

Figure 12: Implicit modeling and concept-based overloading don't mix. 

memory to fit the incoming elements. The second constructor requires the iterators 
to model Forward Iterator, so the algorithm makes a first pass through the iterator 
range to determine its length, then resizes the vector's memory to the appropriate 
size, and finally makes a second pass through the iterator range, filling in the 
elements of the vector. 

Consider the initialization of a vector from an istream_iterator<int> (an iterator 
over integers from the standard input). To determine which constructor to call, 
the C++ compiler would need to deduce whether istream_iterator implements For- 
ward Iterator and Input Iterator. Based on the syntactic constraints captured in the 
concept definitions, istream_iterator appears to model both concepts, so overload 
resolution would choose the constructor for the more refined concept, Forward 
Iterator (Figure [4]). However, istream_iterator does not, in fact, model Forward It- 
erator because it lacks the ability to make multiple passes through its range. Thus, 
the run-time behavior would be rather surprising: instead of filling the vector with 
the first n integers from standard input, it would use the n+1 through 2n integers 
to fill in the vector (supposing there is that much input available). 

The ability to make multiple passes through a range is an example of a seman- 
tic constraint. Another example of a semantic constraint, from the Equality Com- 
parable concept, is that equality should be reflexive, symmetric, and transitive, 
that is, an equivalence relation. The Equality Comparable concept, from the com- 
piler's view, only requires that a type implement operator== , but does not check 
that the operator== is actually an equivalence relation. To fully support semantic 
constraints requires a highly expressive logic and support for theorem proving. 
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template dnputlterator Iterl , Outputlterator Iter2> 
Iter2 copy(lter1 first, Iterl last, Iter2 result); 



template <RandomAccesslterator Iterl , Outputlterator Iter2> 
Iter2 copy(lter1 first, Iterl last, Iter2 result); 



template <lnputlterator Inlterl, Inputlterator Inlter2, Outputlterator Outlter> 
Outlter merge(lnlter1 firstl, Inlterl lastl, Inlter2 first2, Inlter2 Iast2, Outlter result) { 

return copy(first2, Iast2, copy(first1, lastl, result)); 

} 



Figure 13: An example that demonstrates late versus early-bound overloading. 



For example, the Isabelle proof assistant supports semantic constraints with its 
axiomatic type classes [103J. However, there are major research and educational 
challenges that need to be resolved before we can transplant those ideas into an 
mainstream, imperative language such as C++. Thus, the concepts design did not 
include semantic constraints, only syntactic ones. The recommended practice is 
to document semantic constraints in English, as is done for the Standard Template 
Library. 



3.3 Indiana: Two Designs 

Meanwhile Jaakko Jarvi, Jeremiah Willcock, and I began designing a prototype 
language with concepts and constrained templates. Before we proceeded very 
far, we realized that some of our design goals were in conflict. It was clear that 
concept-based overloading was an important language feature, but it seemed to 
conflict with being able to separately compile templates. Even worse, there was 
tension between concept-based overloading and modular type checking. 

Consider the excerpt from the STL merge function together with two over- 



loads of the copy function template in Figure 13 To separately compile merge, 
the C++ compiler needs to decide which overload of copy should be called without 
knowing the actual iterator types. If the C++ compiler performed overload resolu- 
tion only based on the type constraints for merge, it would resolve to the overload 
of copy for Input Iterator. However, consider what happens when using merge 
with the iterators from a vector, which model Random Access Iterator. With the 
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resolution already decided, merge would call the slow version of copy. 

Suppose one forsakes separate compilation in favor of a design that allows late 
binding (after instantiation) for concept-based overloading. The next question is 
whether such a design can support modular type checking. The answer to this 
question is not straightforward, and turns out to be analogous to the problem of 
modular type checking in languages with multi-methods [fT9l 1201 [591 1601 . It is 
also analogous to the problem of dealing with overlapping instance declarations 
in Haskell II691 . It is possible to achieve modular type checking, but the resulting 
type systems are complicated. 

Facing this fork in the design space, we split in two directions: I investigated 
a design with separate compilation and early -bound overloads and Jarvi and Will- 
cock explored a design with late-bound overloads but not separate compilation. 
My investigation led to the design of a calculus for generics, named F g lf80l[8TTl 
and a prototype language named Q [|75l[82l[83ll . The exploration by Jarvi and Will- 
cock did not immediately lead to a concrete design, but their work later became 
the foundation for the Indiana proposal for concepts in C++, which we discuss in 
Section IH 



3.4 A Calculus for Generic Programming 

Here we present a streamlined version of F g to give the reader a feel for the 
design work that went on at Indiana. The purpose of a calculus like F g is not to 
define a language that is for programmers to use, but it is instead a mathematical 
tool to help a language designer better understand the impact of different design 
decisions. In particular, F g was meant to check whether my language design 
provided modular type checking. In addition to informing the design for concepts, 
F g inspired the implicits feature of the Scala language Il68l . 

The inspiration for F g came primarily from Haskell and Standard ML. The F g 
language borrows type classes and instance declarations from Haskell, with some 
modification, to form concepts and models. The main differences are that 1) F g 
does not infer constraints but instead allows an operation name to appear in more 
than one concept, and 2) model declarations are lexically scoped in F g instead of 
being essentially global. With respect to Standard ML, F g borrows abstract types 
and type sharing from ML signatures to provide support for associated types. 



Figure 14 defines the syntax of F g . As the name implies, F g is an extension 
to System F (30l|72]|, which we reviewed in Section [I] F g is also inspired by the 
qualified types of Jones [41 J. For F g , we retain the explicit instantiation syntax of 
System F (e[r]) to avoid complexity in well-understood areas of the design. The 
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concept names c 

integers n 

types t 

model identifier m 

type identifier IT 

constraints C 

expressions e 



term identifier tc 
environments T 



int | t — > t | V«. t | C t | II 

c<r> 

a | m.Il 

m | r = r 

n | e e | Ay:r. e | A<x e | e[r] 
C ^> e | 7r 

concept c<a>{/3; C; a; : r} in e 
model c<r> {/5 = r; x = e} in e 
type a = r in e 

x | m.7r 

T, x : r | T, a | T, C 

r, concept c<a>{/3; C; x : r} 



Figure 14: Syntax of F e . 



language Q (presented in Section [33] ), however, does provides implicit instanti- 
ation (template argument deduction). The overbar notation a indicates a list of 
items in the syntactic category a. For example, r is a list of types: n, r 2 , . . . , r n . 

F G adds several syntactic forms to System F: C =>■ e is a constrained ex- 
pression, with the syntactic category C for expressing constraints. A constraint 
is either a concept constraint of the form c<r> or a same-type constraint of the 
form r = r. The expression n is a term identifier, which is a variable possibly 
prefixed by a sequence of model identifiers. The purpose of such expressions is to 
refer to members of a model. The expression (concept c<a>{/3; C; x : T} in e) 
defines a concept named c for use in e. The /3's are requirements for associated 
types, C are nested constraints, and x : T are the required members of the concept. 
The expression (model c<T> {/3 = T; x = e] in e) establishes that the types T 
together model the concept c. (The common case is for there to be only one mod- 
eling type.) The expression (type a = r in e) aliases the type r to the variable 
a. (In some sense, type aliases are not necessary, because the programmer could 
manually substitute r for a in e. But type alias are important from a software 
engineering point of view because, in generic programming, type expressions can 
grow quite large, so typing r many times inside e, and maintaining the resulting 
code, becomes rather burdensome Il28ll29l .) 
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The type system for F g is defined in Figure 15 As can be seen in the rule 
for function application, type equality is not simply syntactic equality in F g ; the 
addition of same-type constraints means that the type system needs to perform 
equational reasoning over types. The judgment T h r = r gives the declarative 
rules for type equality. These rules can be implemented efficiently using a con- 
gruence closure algorithm Il24ll66l . Otherwise, the typing rules for function and 
generics is the same as System F. 

The introduction (creation) of an expression of type C =>■ r is explicit whereas 
the elimination (use) of such an expression is implicit. This design is intended to 
make it convenient to use generic libraries without adding too much complexity 
to the type system. (We also want to avoid overburdening implementors of the 
language). To type check a constrained expression C =>■ e, we type check e with 
C added as an assumption in the environment. If C is a concept constraint, then 
we also add all constraints that are nested inside the concept into the environment, 
using the notation b(C)r defined as follows: 

K T i = r 2)r = (n = T 2 ) 



b(c<T>) r = c<r>, [a:=r]b(C) T if concept c<a>{(3; C; x : T} G T 

To type check the elimination (use) of an expression of type C => r, we check 
that that the constraint C can be satisfied in the current environment, for which we 
use the judgment r h C. A concept constraint c<r> is satisfied if there is a model 
for that model identifier in the environment. A same-type constraint n = r 2 is 
satisfied if the types are equal in the current environment. 

Note how the typing rules for introducing and eliminating constrained expres- 
sion are nearly mirror images of each other. The introduction rule makes some 
assumptions and the elimination rule discharges an assumption. This kind of mir- 
ror imaging is required to create a type system that ensures type safety. With that 
in mind, it is worth noting a discrepancy here: the elimination rule only discharges 
one assumption whereas the introduction rule adds many assumptions to the envi- 
ronment. The extra assumptions come from nested constraints, and if you look at 
the typing rule for models you see the check for the nested constraints there. 

Type checking a concept definition expression is straightforward, we add the 
concept to the environment and proceed to check the rest of the program. Type 
checking a model definition expression, of the following form, deserves some 
explanation. 

model c<t{> {(3 = r 3 ; x — e} in e 
First, there must be a concept named c in the environment. Second, the nested 
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constraints C within c must be satisfied in the current environment. Third, the 
expressions e must be of the right types, as specified by the concept. Finally, 
we type check the rest of the program e in an environment where we have added 
the model c<r> as an assumption, as well as the type equalities for its choices 
regarding the associated types. 

In the definition of the lookup function, the notation T| c means the environ- 
ment obtained by removing everything but the concept and same-type constraints 
from T. 

Although F g is a small calculus, with the addition of a few standard features 
such as lists, integers, and fix fTTOTl . it can express simple generic algorithms. Fig- 
ure [T6| shows the definition of a generic foldl. The example begins with the defini- 
tion of three concepts that are used to specify constraints on the type parameters 
of foldl. The Semigroup concept is used indirectly, as a nested requirement in- 
side Monoid. The concept Seq has one associated type E for the element type 
of the sequence. The foldl function has one parameter type S for the sequence, 
and constrains S to be something that models Seq. We alias the element type 
of the sequence to the name E, and constrain E to be a model of Monoid. The 
fix operator is to make foldl a recursive function. We access the binary operator 
and identity element of the monoid and use them to implement the core logic of 
the foldl. Much of the syntactic noise in this part of the function is because F G 
does not support function overloading and therefore cannot implicitly introduce 
concept members into the scope of a constrained expression without running into 
problems with name conflicts. The language Q, on the other hand, adds support 
for function overloading. 

The dynamic semantics of F g is defined through a type-directed translation to 
System F, which we refer to here as C(-). Without loss of generality, the semantics 
is defined for programs (closed expressions) of type int. Let — > be the standard 
single-step reduction relation for call-by-value System F and — >* be its reflex- 
ive, transitive closure lITOl . Then the dynamic semantics of F g is defined by the 
following partial function named eval. 

eval(e) - 



n if C(e) — >* n 
| if C(e) diverges 



The translation uses the dictionary-passing approach that is commonly used for 
Haskell type classes 11361 1 1021 . Associated types are translated into extra type 
parameters. We do not give the translation here, but refer the interested reader to 
the paper Essential Language Support for Generic Programming ll80ll8T1l . 
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r h e : r 



r h ei : ri ->■ r 2 T h e 2 : r 3 

r,x:rhe:T' r h n = r 3 

r h n : int r h Ax : r.e : r ->■ r' T h d e 2 : r 2 

T,g h e : r The: Va. r 

r h Ace. e : V<x r T h e[r'] : [a := t']t 

r,b(C) r I- e : r rhe:C^r V \- C 

ThC^e:C^T " ~ ' Their 

T, a = t' h e : r lookup(n, T) = r 

T h type a = r'ine:r ri-7r:r 

r, concept c<q>{/3; C; x : 5} h e : T 
T h concept c<a>{/3; C; x : S} in e : T 

concept c<a>{/3; C; x : r 2 } G T r, a = t\, (3 = T3 h C 
T, a = n, /3 = r 3 h e : T, c<Tj~>, c<t[>./3 = T3 h e : T4 
T h model c<tT> {/3 = T3; x = e} in e : T4 

c<r 7 > £ T rhr = T' T h n = r 2 

r h c <r> " r h (n = r 2 ) 

The congruence closure (with respect to — V, =>) of the following: 

n = r 2 g r rhri = ^ r h rii = n 2 

n-ct = a r h n = r 2 ri- c<ti>. rii = c<T^>.n 2 

lookup(lT, T) = T 

lookup(x, r) = r if x : r G T 

lookup (c<r>. 7T, T) = lookup(TT, (r| c , a = r, C, x : r')) 

if T h c<r> and concept c<a>{/3; C; x : r'} G T 

Figure 15: The type system of F G . 



r h c 



Thr = r 
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concept Semigroup<a> { ; ; binary_op : a ->■ a ->■ a } in 

concept Monoid<a> { ; Semigroup<a>; identity_elt : a } in 

concept Seq<S> { E 1 ; ; isnull : S -> bool, head : S E, tail : 5 -> 5 } in 

let foldl = (A 5. Seq<5> 

type £ = Seq<5>.£ in 

Monoid<£> =>- 

fix (A r : 5 -»■ J5. A Is : S. 

let binary_op = Monoid<£>.Semigroup<.E>.binary_op in 

let identity_elt = Monoid<£>.identity_elt in 

if Seq<5>. isnull Is then identity_elt 

else binary_op(Seq<5>.head Is, r(Seq<5>.tail Is)))) 

in 

model Semigroup<int> { ; binary_op = A x:int. A y:int. x + y } in 
model Monoid<int> { ; identity_elt = } in 

model Seq<int list> {E=int; isnull=A Is. null? Is, head=A Is. car Is, tail=A Is. cdr Is} in 
foldl[int list] [2,3,4] 

Figure 16: Example of a generic fold in F g . 

Getting back to the main point of F g , does it provide modular type checking? 
The answer is yes and that can be seen by inspecting the type rules in Figure [15] 
The rules for functions and generics are the same as those of System F, which we 
inspected for modularity in Section [TTTj The important addition is the constrained 
expression C => e. The introduction rule for constrained expressions only refers 
to the constraint C and body e. The elimination rule for constrained expressions 
only depends on the type of expression e, that is, the type C =>- r, and the current 
environment T. 

However, an experienced language designer knows that it is easy to create a 
modular type system by cheating, that is, by creating a type system that does not 
guarantee type safety. Thus, the type safety result for F g plays an important role 
in verifying that F g has a modular type system. The type safety theorem for F g is 
stated as follows. 

Theorem 1 (Type Safety). If\- e : int, then either eval(e) = n for some integer n 
or eval(e) = t- 

System F is type safe, so proving type safety for F g amounts to proving that the 
translation C is type preserving. Indeed, I proved the following lemma [1501 1ST! . 

Lemma 1 (C is type preserving). If\- e : r, then h C(e) : C(r). 
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The proof of type safety then proceeds as follows. 

Proof of Type Safety. We are given that h e : int. By Lemma[TJ we have h C(e) : 
int (we have C(int) = int). Then by the type safety of System F, C(e) either re- 
duces to a value of type int, in which case the value is an integer, or C(e) diverges. 
In the first case, we have eval(e) = n and in the second case, eval(e) = f. Either 
way, our proof is complete. □ 

In addition to having a modular type system, F g supports separate compila- 
tion, as F g translates to System F, and it is straightforward to separately compile 
System F as we discussed in Section [LT| 



3.5 A Prototype Language for Generic Programming 

To gain some practical experience in using this language design, I developed a 
prototype language named Q 11751 [821 [831 . Then, as a case study, I ported a large 
portion of the STL to Q. In addition to the features in F s , Q included template ar- 
gument deduction, function overloading, concept refinement, parameterized mod- 
els, a basic module system, and simple classes. The overall experience of porting 
the STL to Q was pleasant: short error messages and short compile times. 

As mentioned earlier, in deciding to support separation compilation, the design 
for Q gave up late-bound concept-based overloading. However, Q does provide 
early-bound concept-based overloading, and in the process of porting the STL 
to Q, I discovered workarounds for mimicking late-bound overloads using early- 
bound overloads. 



Recall the merge function from Figure 13 When ported to Q, the calls to 



copy always resolve to the slower version for Input Iterator, even when merge is 



used on a sequence that models Random Access Iterator. Figure 17 shows the 
workaround for mimicking late-bound overloading. The main idea is to create a 
new concept for the overloaded function, in this case for copy. Here we name the 
concept CopyRange. Instead of calling copy directly, merge adds CopyRange to its 
constraints (in Q, constraints go in the where clause), and then calls the copy_range 
operation instead of copy. 

With this change, the choice of which model of CopyRange is used, and there- 
fore which copy, is made at the point where merge is instantiated, where the con- 
crete iterator is known. However, it would place a burden on users of merge if 
they had to create extra model definitions for CopyRange. To solve this problem, 
we create two parameterized model definitions for CopyRange, one for models 
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concept CopyRange<l1 ,I2> { 
fun copy_range(M ,11 ,12) -> 12; 

}; 

model <lter1 ,lter2> where { lnputlterator<lter1>, ... } 
CopyRange<lter1 ,lter2> { 
fun copy_range(lter1 first, Iterl last, Iter2 result) -> Iter2 
{ return copy(first, last, result); } 

}; 

model <lter1 ,lter2> where { RandomAccesslterator<lter1>, ... } 
CopyRange<lter1 ,lter2> { 
fun copy_range(lter1 first, Iterl last, Iter2 result) -> Iter2 
{ return copy(first, last, result); } 

}; 

fun merge<lter1 ,lter2,lter3> 

where { CopyRange<lter2,lter3>, CopyRange<lter1 ,lter3> } 
(Iterl firstl, Iterl lastl, Iter2 first2, Iter2 Iast2, Iter3 result) -> Iter3 { 
... return copy_range(first2, Iast2, copy_range(first1 , lastl, result)); 

} 

Figure 17: Workaround for mimicking late-bound overloading. 

of Input Iterator and one for models of Random Access Iterator. With these two 
parameterized models, the user of merge does not need to do any extra work. 

The attentive reader may wonder how merge, using the above workaround, can 
be separately compiled. The reason is that Q uses the same dictionary-passing im- 
plementation model as F g . Thus, Q generates just one version of merge that takes a 
dictionary for CopyRange, which includes a pointer to the appropriate copy_range 
function. The cost of separate compilation, and this dictionary-passing model, 
is an extra level of indirection and therefore some run-time overhead. However, 
the Q compiler is free to optimize calls to merge, through function specialization 
and constant-propagation through the dictionaries, to remove the run-time over- 
head in situations where performance outweighs separate compilation. Jones Il42ll 
describes this optimization in the context of Haskell type classes. 
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4 The Indiana Proposal 



After the Kona meeting in 2003, two C++ standards meetings (one year) elapsed 
without an updated proposal from the Texas A&M team. In the Fall of 2004, 
the Indiana team began to worry about the progress on concepts with respect to 
getting an extension into C++0x. Around the same time, Douglas Gregor arrived 
at Indiana University to do a post-doc with Andrew Lumsdaine, and Douglas was 
excited to join in the design effort and to implement concepts in the GNU C++ 
compiler. The prototype would be named ConceptGCC. The Indiana team began 
in earnest to develop a proposal for C++0x in the Fall of 2004. The design differed 
from Q in several respects, which we discuss in the next few paragraphs. 

Achieving separate compilation for C++ was a non-starter because we had 
to maintain backwards compatibility, and existing features of C++ such as user- 
defined template specializations interfere with separate compilation (as discussed 
in Section 2.2). With that in mind, it made sense to use the late-bound approach 
to concept-based overload resolution ll39l . 

In general, performance is a high priority for C++ programmers, so we needed 
an implementation that would yield zero run-time overhead. The dictionary- 
passing implementation used in Q comes with roughly the same overhead as vir- 
tual method dispatch. To improve upon this, we devised an approach that instead 
resolves all uses of concept operations at compile time ll33l . 

The third difference between the Indiana proposal for C++ and Q was that 
models would not be lexically scoped but instead they would reside in the same 
namespace as their concept. This design choice was made primarily to simplify 
the implementation but it meant that model definitions would not be modular. 

Compared to the Texas proposal, there were also several differences. Instead 
of usage patterns to specify concept operations, the Indiana proposal went with 
pseudo-signatures, a design that the Texas team had considered but discarded [|92l . 
The idea with pseudo-signatures is to relax the rules for matching up functions to 
concept operations. Consider the example in Figure [T8] in which class A models 
concept C (written in the syntax of the Indiana proposal). The concept requires a 
function f taking two parameters of type A and B and has return type A. (In this 
case, A is substituted for T.) However, the only function named f in the scope of 
the model definition has both parameters at type A and a return type of B. With 
pseudo-signatures, this function f satisfies the requirement because B is implicitly 
convertible to A. 

The strength of pseudo-signatures is that it provides flexibility for the client 
of a template while at the same time providing precision for the implementor of 
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class A {}; 

class B : public A {}; 

template<typeid T> 
concept C { 

A f(T, B); 

}; 

B f(A, A) { return B(); } 
model C<A> { }; 

// This model is OK because B is convertible to A. 



Figure 18: Example of a pseudo-signature. 



a template. The pseudo-signature approach was straightforward to implement. 
On the client side, finding implementations that match a pseudo-signature can be 
accomplished with the normal algorithm for function overload resolution. On the 
implementation side of a template, a pseudo-signature is treated just like a normal 
signature for the purposes of type checking. That is, what you see is what you get. 

The Indiana proposal also differed from the Texas proposal in that it did not 
support implicit modeling, but instead relied on model definitions to establish the 
modeling relationship between a class and a concept. We did not want to expose 



programmers to the kind of accidental run-time errors discussed in Section 3.3 



With respect to operators for combining concepts, the Indiana proposal only in- 
cluded conjunction. 

Figure [19] shows an example of a concept definition and constrained template 
from the Indiana proposal. 

The Indiana proposal was completed and submitted as document number N1758 
to the C++ standards committee in January of 2005 11851 . 



5 The Texas Rebuttal 

Stroustrup and Dos Reis ll9~71 submitted a revised proposal in April of 2005 and 
submitted a paper describing their design to POPL 2006 [[221 l23l . The proposal 
moved closer to the Indiana proposal in several respects, but there were signifi- 
cant differences. The revised proposal included where clauses to enable the use of 
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template<typeid lter> 

concept Inputlterator : EqualityComparable<lter>, 
CopyConstructible<lter>, Assignable<lter> { 
typename value_type; 
typename reference; 

require Convertible<reference, value_type>; 
lter& operator++(lter&); 
reference operator*(lter); 

}; 

template<typeid Inlter, typeid Outlter> 

where { lnputlterator<lnlter>, Outputlterator<Outlter>, 

lnlter::value_type == Outlter::value_type } 
Outlter copy(lnlter a, Inlter b, Outlter out) { 

while (a != b) *out++ = *a++; 

return out; 

} 



Figure 19: Example of a concept and constrained template in the Indiana proposal. 



multi-type concepts and added associated types. The revised proposal also added 
model declarations, under the name static_assert. However, unlike the Indiana 
proposal, model declarations were optional, so the Texas proposal retained im- 
plicit modeling. The Texas proposal kept usage patterns for specifying concept 
operations and an associated technical report defined an algorithm for converting 
usage patterns into type signatures [22] . The proposal also retained the || and ! 
operators for combining concepts. 

To address the concern regarding accidental run-time errors, discussed in Sec- 
tion |3.3[ Stroustrup and Dos Reis ||971l proposed using negative model declara- 
tions, that is, declarations that a type does not implement a concept. For the exam- 
ple in Section |33j they suggested adding a declaration stating that istream_iterator 
does not model Forward Iterator. 

At the Mont Tremblant C++ standards meeting in October 2005, there was 
considerable disagreement regarding the design of concepts. The Indiana team 
was not in favor of negative model declarations because the number of properties 
that a type does not satisfy is open ended and much larger than the number of 
properties that a type does satisfies. Thus, negative model declarations did not 
seem like an economical approach to solving this problem. 
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With respect to usage patterns and the || and ! operators for combining con- 
cepts, there was no publicly available compiler implementation, so doubt re- 
mained regarding the usability and efficiency of these design choices. 

6 The Compromise at Adobe 

Alexander Stepanov invited the Texas and Indiana teams to a meeting at Adobe 
Systems Inc. in San Jose. The goal of the meeting was to resolve the outstanding 
differences between the two proposals, and indeed, the teams were able to agree 
on a compromise design. The high points of the compromise were as follows. 
The joint design would include || and ! operators for combining concepts, but it 
would use pseudo-signatures instead of usage patterns. With respect to model 
declarations, the compromise was to have two kinds of concepts. The default 
kind of concept would require explicit model declarations whereas a concept that 
started with the keyword auto could be modeled implicitly. The Indiana team was 
receptive to this compromise because it balanced convenience and safety. 

Over the next few months, the Texas and Indiana teams worked together to 
document the compromise design and published the results at OOPSLA 2006 11331 . 
One of the syntactic changes that happened during this time, thanks to research 
by Beman Dawes, was that the keyword model was replaced by conceptjmap to 
minimize the number of existing C++ programs that would break when upgraded 
to the new version of C++. 

To avoid "too many cooks in the kitchen", Stroustrup and Gregor teamed up to 
write the compromise proposal to the C++ standards committee, which resulted in 
the document N2042 (341 in June of 2006 and the revision N2081 in September. 
The proposal was well received by the C++ standards committee. 

7 Proposed Wording and Acceptance 

In 2007, work began in earnest to draft the wording that would go into the C++ 
standard. The dialect of English used in the C++ standard is lovingly referred to as 
"standardese". Unfortunately, writing standardese is a slow process. Gregor and 
Stroustrup wrote the initial draft and several revisions, producing the documents 
N2193, N2307, and N2398. In the Fall of 2007, Widman and I began to pitch in 
with the writing, and helped produce N2421, N2501, and N2520. 

During this time, the design evolved in a few respects. The where keyword 
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was changed to requires because requires would cause fewer existing C++ pro- 
grams to break. Also, the || constraints were removed for lack of implementation 
experience. 

The initial implementation approach for concepts required the generation of 
forwarding functions within each model (331. While these function calls can be 
statically resolved (and usually inlined), there was still some run-time overhead 
with ConceptGCC. Also, some optimizations such as copy-elision could not be 
applied with the forwarding functions in the way. To address these issues, Gre- 
gor devised an alternative compilation approach that did not rely on forwarding 
functions but instead inlines the body of the forwarding functions into the tem- 
plate OTTl . Unfortunately, this approach opened up another hole in the modularity 
of the type system: there could be ambiguities after instantiation that cause type 
errors. 

Meanwhile, I revisited the decision that model declaration would live in the 
same namespace as their concept, proposing to allow model declarations to appear 
in any namespace and to use the normal (lexical) name lookup rules for concept 
maps 11761 . This proposal was referred to as "scoped concept maps". In 2007, 
scoped concept maps were approved and proposed wording for the standard was 
drafted by Widman and 1 11741 . 

In addition to the work on the concepts feature itself, there was considerable 
work to update the C++ standard library to use concepts. Gregor, Halpern, Lums- 
daine, Marcus, Witt, and I with the help of many others, drafted the changes to 
the C++ standard, producing N2500, N2502, N2677, and their revisions. 

At the September 2008 meeting of the C++ standards committee in San Fran- 
cisco, the concepts proposal was voted into the working draft for C++0x! In the 
next few months, the editor of the working draft, Pete Becker, began merging the 
proposed wording for concepts and the updates to the standard library into the C++ 
standard. At this point, we believed it would be smooth sailing, with the remain- 
ing work on the order of fixing typos and resolving ambiguities in the wording. 
We hoped that the entire working draft would be finalized in a year or so and then 
approved as the new ANSI and ISO standard for C++. 

8 The Removal of Concepts 

In the months following the San Francisco meeting, heated discussions occurred 
on the C++ standards committee mailing list. There were two threads of discus- 
sion. The first thread was kicked off by Howard Hinnant, with the email titled 
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"Are concepts required of Joe Coder?". The question was whether a programmer 
using the standard library would need to be aware of concepts. My simple answer 
is yes. Concepts inform the programmer regarding which types can be used with 
which templates. In fact, before the addition of the concepts feature to C++, pro- 
grammers needed to be aware of concepts (in the form of documentation) for the 
same reason. 

However, there was a concern that the addition of concepts would create a 
learning curve that would be too great for the average C++ programmer. In par- 
ticular, there was concern that it would be too burdensome for programmers to 
write lots of concept maps. So an important question is: in which situations does 
a programmer need to write concepts maps? 

The most common place for concept maps is immediately after a class defi- 
nition. The author of the class knows that the class models various concepts and 
therefore documents these facts for users of the class, including the C++ compiler. 
This use of concept maps is analogous to a class inheriting from an abstract base 
class (that is, an interface). Millions of programmers have learned object-oriented 
languages and inheritance, so learning to use concept maps cannot be too great of 
a hurdle. Furthermore, many concepts would be auto concepts, for which concept 
maps are not required. 

A less common place for concept maps is when a programmer wants to use 
one library with another library, but the library authors did not intended the li- 
braries to be used together. In such cases a programmer can use concept maps to 
retroactively specify that a class implements a concept. Retroactive inheritance 
has long been desired in object-oriented languages. The external polymorphism 
design pattern provides a workaround Il26ll for languages without retroactive in- 
heritance and there have been many language extensions that provide retroactive 
inheritance, such as signatures 0152) and aspects [49]. So this use of concept 
maps is a nice advance compared to traditional forms of inheritance. 

In a reaction to the thread "Are concepts required of Joe Coder?" and to 
move closer to his original design, Stroustrup proposed to remove explicit con- 
cepts (concepts that require concept maps) and replace them with explicit refine- 
ment [|94l . However, the semantics of explicit refinement was not clear, so it was 
very difficult for committee members to evaluate the proposal. 

The second thread of discussion concerned the state of implementations of the 
concepts feature [98]. Although Gregor had implemented a prototype, Concept- 
GCC, the concept specification had moved beyond the prototype with changes 
and additions. Also, there were problems with the prototype: bugs and slow com- 
pile times, that made it difficult to use ConceptGCC with large generic libraries. 
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(Gregor is not to blame in this regard, as implementing concepts inside the Gnu C 
compiler was a heroic task.) The slow compile times also worried many commit- 
tee members, even though it was an engineering issue and not a theoretical limit 
that was causing the slow down. An algorithm for fast type checking had been 
demonstrated in the Q prototype [7511811 . 

At the Frankfurt meeting in July 2009, the C++ standard committee voted with 
the following options. 

1. Continue with the current specification of concepts. 

2. Remove explicit concepts and add explicit refinement. 

3. Remove concepts from the working draft of the C++ standard. 

Most of the committee members felt it was too late for major changes, and without 
Stroustrup supporting the status quo, the overwhelming majority voted to remove 
concepts. Needless to say, everyone who had been involved in the development of 
concepts was deeply disappointed. 

9 Conclusion 

So where do concepts go from here? The next round of C++ standardization will 
most likely be in five years. However, the more important question is whether C++ 
programmers, and the C++ committee in particular, will be able to gain experience 
using concepts so that they can better evaluate the tradeoffs regarding different 
designs. So there is great need for an implementation of concepts. However, for 
the next few years, most commercial C++ compiler vendors will be focused on 
implementing the features that made it into C++0x. Also, implementing concepts 
is an expensive endeavor, and without consensus in the C++ committee on the 
design, such an expense is risky from a business point of view. 

There is some hope that Douglas Gregor, heading up the C++ compiler team at 
Apple, Inc., together with Andrew Lumsdaine's research group at Indiana Univer- 
sity, will be able to implement concepts within the Clang LLVM-based compiler. 
On another front, I am leading a group at the University of Colorado to add con- 
cepts to the Chapel programming language [18J with funding from the U.S. De- 
partment of Defense. While Chapel is somewhat different from C++, this may give 
some programmers more exposure to concepts and generate feedback regarding 
the design. 



42 



Acknowledgments 



Thank you to Jeremy Gibbons for organizing the Spring School on Generic and 
Indexed Programming and for inviting me to give a lecture there on the C-H-Ox 
concept effort. Thank you Oleg Kiselyov for your many kind suggestions for 
improvement for this article. Thanks to Bjarne Stroustrup for his corrections and 
thanks to the programming languages group at the University of Colorado for your 
helpful feedback and proof reading. The writing of this article was supported by 
the NSF in the form of a CAREER award, CCF 0846121 . 

References 

[1] D. Abrahams and A. Gurtovoy. C+ + Template Metaprog ramming: Concepts, Tools, and 
Techniques from Boost and Beyond ( C++ in Depth Series). Addison- Wesley Professional, 
2004. ISBN 0321227255. 

[2] F. Alet, P. Dayal, A. Grzesik, A. Honecker, M. Koerner, A. Laeuchli, S. R. Manmana, I. P. 
McCulloch, F. Michel, R. M. Noack, G. Schmid, U. Schollwoeck, F. Stoeckli, S. Todo, 
S. Trebst, M. Troyer, P. Werner, and S. Wessel. The ALPS project: open source software 
for strongly correlated systems. J.PHYS.SOC.JPN., 74:30, 2005. 

[3] A. Alexandrescu. Modern C++ design: generic programming and design patterns applied. 
Addison-Wesley Longman Publishing Co., Inc., Boston, MA, USA, 2001. ISBN 0-201- 
70431-5. 

[4] M. H. Austern. Generic programming and the STL: Using and extending the C+ + Standard 
Template Library. Professional Computing Series. Addison-Wesley Longman Publishing 
Co., Inc., 1998. ISBN 0-201-30956-4. 

[5] G. Baumgartner and V. F. Russo. Signatures: A language extension for improving type 
abstraction and subtype polymorphism in C++. Software: Practice and Experience, 25(8): 
863-889, 1995. ISSN 1097-024X. doi: 10.1002/spe.4380250803. URL |http : //dx . | 
Idol", org/10. 100 2/spe. 4 3802508031 

[6] J.-D. Boissonnat, F. Cazals, F. Da, O. Devillers, S. Pion, F. Rebufat, M. Teillaud, and 
M. Yvinec. Programming with CGAL: the example of triangulations. In Proceedings of 
the Fifteenth Annual Symposium on Computational Geometry, pages 421^-22. ACM Press, 
1999. ISBN 1-58113-068-6. 

[7] G. Bracha, M. Odersky, D. Stoutamire, and P. Wadler. Making the future safe for the past: 
adding genericity to the java programming language. In Proceedings of the 13 th ACM SIG- 
PLAN conference on Object-oriented programming, systems, languages, and applications, 
OOPSLA '98, pages 183-200, New York, NY, USA, 1998. ACM. ISBN 1-58113-005- 
8. doi: http://doi.acm.org/10.1145/286936.286957. URL jhttp : //doi . acm . org/ 10 . | 
[TT45/286936. 2869571 



43 



[8] K. Bruce, L. Cardelli, G. Castagna, G. T. Leavens, and B. Pierce. On binary methods. 
Theor. Pract. Object Syst, 1:221-242, December 1995. ISSN 1074-3227. URL |http:| 
|//dl . acm.org/citat ion. cfm?id=2 3 08 4 9 . 230854| 

[9] K. B. Bruce, M. Odersky, and P. Wadler. A statically safe alternative to virtual types. In 
ECCOP '98: Proceedings of the 12th European Conference on Object-Oriented Program- 
ming, pages 523-549, London, UK, 1998. Springer- Verlag. ISBN 3-540-64737-6. 

[10] R. M. Burstall and J. A. Goguen. Putting theories together to make specifications. In 
IJCAI'77: Proceedings of the 5th international joint conference on Artificial intelligence, 
pages 1045-1058, San Francisco, CA, USA, 1977. Morgan Kaufmann Publishers Inc. 

[11] R. M. Burstall and J. A. Goguen. The semantics of CLEAR, a specification language. 
In Proceedings of the Abstract Software Specifications, 1979 Copenhagen Winter School, 
pages 292-332, London, UK, 1980. Springer- Verlag. ISBN 3-540-10007-5. 

[12] R. M. Burstall, D. B. MacQueen, and D. T. Sannella. HOPE: An experimental applicative 
language. In LFP '80: Proceedings of the 1980 ACM conference on LISP and functional 
programming, pages 136-143, New York, NY, USA, 1980. ACM. 

[13] P. Canning, W. Cook, W. Hill, W. Olthoff, and J. C. Mitchell. F-bounded polymorphism 
for object-oriented programming. In FPCA '89: Proceedings of the fourth international 
conference on Functional programming languages and computer architecture, pages 273- 
280. ACM, 1989. ISBN 0-89791-328-0. 

[14] L. Cardelli and P. Wegner. On understanding types, data abstraction, and polymorphism. 
ACM Comput. Sun'., 17(4):47 1-523, 1985. ISSN 0360-0300. 

[15] H. Cejtin, M. Fluet, S. Jagannathan, and StephenWeeks. MLton documentation, July 2007. 

URL |http : / /mlton . org/Documentation| 

[16] M. M. T. Chakravarty, G. Keller, and S. P. Jones. Associated type synonyms. In ICFP '05: 
Proceedings of the tenth ACM SIGPLAN international conference on Functional program- 
ming, pages 241-253, New York, NY, USA, 2005. ACM Press. ISBN 1-59593-064-7. 

[17] M. M. T. Chakravarty, G. Keller, S. P. Jones, and S. Marlow. Associated types with class. 
In POPL '05: Proceedings of the 32nd ACM SIGPLAN-SIGACT symposium on Principles 
of programming languages, pages 1-13, New York, NY, USA, 2005. ACM Press. ISBN 
1-581 13-830-X. 

[18] B. Chamberlain, S. Deitz, S. Hoffswell, J. Plevyak, H. Zima, and R. Diaconescu. Chapel 
Specification. Cray Inc, 0.796 edition, October 2010. 

[19] C. Chambers and G. T. Leavens. Typechecking and modules for multimethods. ACM 
Trans. Program. Lang. Syst, 17:805-843, November 1995. ISSN 0164-0925. doi: 
http://doi.acm.Org/10.l 145/218570.218571. URL |http : / /doi . acm. org/10 . 1145/| 
1218570 .2185711 



44 



[20] C. Clifton, T. Millstein, G. T. Leavens, and C. Chambers. MultiJava: Design rationale, 
compiler implementation, and applications. ACM Trans. Program. Lang. Syst., 28:517- 
575, May 2006. ISSN 0164-0925. doi: http://doi.acm.org/10.1145/1133651.1133655. URL 

|http: //doi. acm.org/ 10. 1145/1133 651 .1133 6551 

[21] B. Dawes, D. Abrahams, and R. Rivera. Boost C++ libraries. 

[22] G. Dos Reis and B. Stroustrup. Specifying C++ concepts. Technical Report N1886, 
ISO/IEC JTC 1 SC22 WG21, 2005. 

[23] G. Dos Reis and B. Stroustrup. Specifying C++ concepts. In POPL '06: Conference record 
of the 33 rd ACM SIGPLAN-SIGACT symposium on Principles of programming languages, 
pages 295-308, New York, NY, USA, 2006. ACM. ISBN 1-59593-027-2. 

[24] P. J. Downey, R. Sethi, and R. E. Tarjan. Variations on the common subexpression problem. 
J. ACM, 27(4):758-771, 1980. ISSN 0004-5411. 

[25] E. Ernst, gbeta - a Language with Virtual Attributes, Block Structure, and Propagating, 
Dynamic Inheritance. PhD thesis, Department of Computer Science, University of Aarhus, 
Arhus, Denmark, 1999. 

[26] E. Gamma, R. Helm, R. Johnson, and J. Vlissides. Design patterns: elements of reusable 
object-oriented software. Addison-Wesley Longman Publishing Co., Inc., Boston, MA, 
USA, 1995. ISBN 0-201-63361-2. 

[27] R. Garcia and A. Lumsdaine. MultiArray: a C++ library for generic programming with 
arrays. Softw., Pract. Exper, 35(2): 159-1 88, 2005. 

[28] R. Garcia, J. Jarvi, A. Lumsdaine, J. G. Siek, and J. Willcock. A comparative study of 
language support for generic programming. In OOPSLA '03: Proceedings of the 18th 
Annual ACM SIGPLAN Conference on Object-oriented Programing, Systems, Languages, 
and Applications, pages 115-134. ACM Press, 2003. ISBN 1-58113-712-5. 

[29] R. Garcia, J. Jarvi, A. Lumsdaine, J. G. Siek, and J. Willcock. An extended comparative 
study of language support for generic programming. Journal of Functional Programming, 
17(2): 145-205, March 2007. 

[30] J.-Y. Girard. Interpretation fonctionelle et elimination des coupures de V arithmetique 
d'ordre superieur. PhD thesis, Paris, France, 1972. 

[31] D. Gregor. Type-soundness and optimization in the concepts proposal type-soundness and 
optimization in the concepts proposal types-soundness and optimization in the concepts 
proposal. Technical Report N2576, ISO/IEC JTC 1 SC22 WG21, 2008. 

[32] D. Gregor and J. G. Siek. Explicit model definitions are necessary. Technical Report 
N 1798=05-0058, ISO/IEC JTC 1, Information Technology, Subcommittee SC 22, Program- 
ming Language C++, May 2005. 



45 



[33] D. Gregor and J. G. Siek. Implementing concepts. Technical Report N1848=05-0108, 
ISO/IEC JTC 1, Information Technology, Subcommittee SC 22, Programming Language 
C++, August 2005. 

[34] D. Gregor and B. Stroustrup. Concepts. Technical Report N2042, ISO/IEC JTC 1 SC22 
WG21, June 2006. 

[35] D. Gregor, J. Jarvi, J. G. Siek, G. D. Reis, B. Stroustrup, and A. Lumsdaine. Concepts: 
Linguistic support for generic programming in C++. In Proceedings of the ACM SIG- 
PLAN Conference on Object-oriented Programming, Systems, Languages, and Applica- 
tions (OOPSLA'06), Oct. 2006. 

[36] C. V. Hall, K. Hammond, S. L. Peyton Jones, and P. L. Wadler. Type classes in Haskell. 
ACM Trans. Program. Lang. Syst., 18(2): 109-138, 1996. ISSN 0164-0925. 

[37] J. Jarvi. Tuple types and multiple return values. C/C++ Users Journal, 19:24-35, Aug. 
2001. 

[38] J. Jarvi, G. Powell, and A. Lumsdaine. The Lambda Library : unnamed functions in C++. 
Software — Practice and Experience, 33(3):259-291, 2003. 

[39] J. Jarvi, D. Gregor, J. Willcock, A. Lumsdaine, and J. G. Siek. Algorithm specialization 
in generic programming - challenges of constrained generics in C++. In PLDI '06: Pro- 
ceedings of the ACM SIGPLAN 2006 conference on Programming language design and 
implementation, New York, NY, USA, June 2006. ACM Press. 

[40] R. D. Jenks and B. M. Trager. A language for computational algebra. In SYMSAC '81: 
Proceedings of the fourth ACM symposium on Symbolic and algebraic computation, pages 
6-13, New York, NY, USA, 1981. ACM. ISBN 0-89791-047-8. 

[41] M.P.Jones. Qualified Types: Theory and Practice. Distinguished Dissertations in Com- 
puter Science. Cambridge University Press, 1994. 

[42] M. P. Jones. Dictionary-free overloading by partial evaluation. Lisp Symb. Comput., 8: 
229-248, September 1995. ISSN 0892-4635. doi: 10.1007/BF01019005. URLhttp: 

|//dl .acm.org/citation.cfm?id=22307 9 . 223082| 

[43] G. L. S. Jr. An overview of COMMON LISP. In LFP '82: Proceedings of the 1982 ACM 
symposium on LISP and functional programming, pages 98-107, New York, NY, USA, 
1982. ACM Press. ISBN 0-89791-082-6. 

[44] S. Kaes. Parametric overloading in polymorphic programming languages. In H. Ganzinger, 
editor, ESOP '88, volume 300 of Lecture Notes in Computer Science, pages 131-144. 
Springer Berlin / Heidelberg, 1988. ISBN 978-3-540-19027-1. URL |http : //dx . doi . | 
|org/10 . 1007/3-54 0-1902 7-9_9| 



46 



[45] D. Kapur, D. R. Musser, and A. A. Stepanov. Operators and algebraic structures. In FPCA 
'81: Proceedings of the 1981 conference on Functional programming languages and com- 
puter architecture, pages 59-64, New York, NY, USA, 1981. ACM Press. ISBN 0-89791- 
060-5. 

[46] D. Kapur, D. R. Musser, and A. A. Stepanov. Tecton: A language for manipulating generic 
objects. In Program Specification, Proceedings of a Workshop, pages 402^414, London, 
UK, 1982. Springer- Verlag. ISBN 3-540-11490-4. 

[47] A. Kennedy and S. Don. Design and implementation of generics for the .net common 
language runtime. In Proceedings of the ACM SIGPLAN 2001 conference on Program- 
ming language design and implementation, PLDI '01, pages 1-12, New York, NY, USA, 
2001. ACM. ISBN 1-58113-414-2. doi: http://doi.acm.org/10.1145/378795.378797. URL 

|http://doi .acm.org/10.1145/3787 95.3787T7l 

[48] A. Kershenbaum, D. Musser, and A. Stepanov. Higher order imperative programming. 
Technical Report 88-10, Rensselaer Polytechnic Institute, 1988. 

[49] G. Kiczales, J. Lamping, A. Menhdhekar, C. Maeda, C. Lopes, J.-M. Loingtier, and J. Irwin. 
Aspect-oriented programming. In Proceedings European Conference on Object-Oriented 
Programming, volume 1241, pages 220-242. Springer- Verlag, Berlin, Heidelberg, and New 
York, 1997. 

[50] O. Kiselyov and S. Peyton-Jones. Choosing a type-class instance based on the context, 
2008. URL |http : //haskell . org/haskellwiki/GHC/AdvancedOverlap| 

[51] U. Kothe. Handbook on Computer Vision and Applications , volume 3, chapter Reusable 
Software in Computer Vision. Acadamic Press, 1999. 

[52] K. Laufer, G. Baumgartner, and V. F. Russo. Safe structural conformance for java. The 
Computer Journal, 43(6):469-481, 2000. doi: 10.1093/comjnl/43.6.469. URL |http:[ 

|/ /com jnl . oxford journals . org/content/43/ 6/ 4 69 . abstract) 

[53] L.-Q. Lee, J. G. Siek, and A. Lumsdaine. The generic graph component library. In OOPSLA 
'99: Proceedings of the 14th ACM SIGPLAN conference on Object-oriented programming, 
systems, languages, and applications, pages 399^-14, New York, NY, USA, 1999. ACM 
Press. ISBN 1-58113-238-7. 

[54] X. Leroy. The Objective Caml system: Documentation and user's manual, 2000. With 
Damien Doligez, Jacques Garrigue, Didier Remy, and Jerome Vouillon. 

[55] B. Liskov, R. Atkinson, T. Bloom, E. Moss, C. Schaffert, B. Scheifler, and A. Snyder. CLU 
reference manual. Technical Report LCS-TR-225, MIT, October 1979. 

[56] D. MacQueen. Modules for standard ML. In LFP '84: Proceedings of the 1984 ACM 
Symposium on LISP and functional programming, pages 198-207, New York, NY, USA, 
1984. ACM. ISBN 0-89791-142-3. 



47 



[57] J. McCarthy. Recursive functions of symbolic expressions and their computation by ma- 
chine, pail i. Commun. ACM, 3(4): 184-195, 1960. ISSN 0001-0782. 

[58] S. Meyers. Effective STL: 50 specific ways to improve your use of the standard template 
library. Addison- Wesley Longman Ltd., Essex, UK, UK, 2001. ISBN 0-201-74962-9. 

[59] T. Millstein, C. Frost, J. Ryder, and A. Warth. Expressive and modular predicate dispatch 
for Java. ACM Trans. Program. Lang. Syst, 31:7:1-7:54, February 2009. ISSN 0164-0925. 
doi: http://doi.acm.org/10.1145/1462166.1462168. URL |http : //doi . acm. org/10 . | 
11145/1462166.14621681 

[60] T. D. Millstein and C. Chambers. Modular statically typed multimethods. In Proceedings 
of the 13th European Conference on Object-Oriented Programming, ECOOP '99, pages 
279-303, London, UK, 1999. Springer- Verlag. ISBN 3-540-66156-5. URL http:// 
Iportal . acm. org/ citation . cfm?id=64 615 6 . 67 9834] 

[61] R. Milner. A theory of type polymorphism in programming. Journal of Computer and 
System Sciences, 17(3):348-375, 1978. 

[62] R. Milner, M. Tofte, and R. Harper. The definition of Standard ML. MIT Press, 1990. ISBN 
0-262-63132-6. 

[63] D. R. Musser and A. Stepanov. Generic programming. In ISSAC: Proceedings of the ACM 
SIGS AM International Symposium on Symbolic and Algebraic Computation, 1988. 

[64] D. R. Musser and A. A. Stepanov. A library of generic algorithms in Ada. In The 1987 
annual ACM SIGAda international conference on Ada, pages 216-225. ACM SIGAda, Dec. 
1987. 

[65] N. C. Myers. Traits: a new and useful template technique. C++ Report, June 1995. 

[66] G. Nelson and D. C. Oppen. Fast decision procedures based on congruence closure. /. 
ACM, 27(2):356-364, 1980. ISSN 0004-541 1. 

[67] M. Odersky, V. Cremet, C. Rockl, and M. Zenger. A nominal theory of objects with depen- 
dent types. In ECOOP '03, Springer LNCS, 2003. 

[68] M. Odersky, P. Altherr, V. Cremet, I. Dragos, G. Dubochet, B. Emir, S. McDirmid, S. Mich- 
eloud, N. Mihaylov, M. Schinz, E. Stenmn, L. Spoon, and M. Zenger. An overview of the 
Scala programming language. Technical Report IC/2004/64, EPFL, 2004. 

[69] S. Peyton Jones, M. Jones, and E. Meijer. Type classes: an exploration of the design space. 
In Proceedings of the 2nd Haskell Workshop, June 1997. 

[70] B. C. Pierce. Types and Programming Languages. MIT Press, 2002. ISBN 0-262-16209-1. 

[71] W. R. Pitt, M. A. Williams, M. Steven, B. Sweeney, A. J. Bleasby, and D. S. Moss. The 
bioinformatics template library: generic components for biocomputing. Bioinformatics, 17 
(8):729-737, 2001. 



48 



[72] J. C. Reynolds. Towards a theory of type structure. In Programming Symposium, volume 19 
of LNCS, pages 408-425. Springer- Verlag, 1974. 



[73] G. L. Russo. An interview with A. Stepanov. URL |http : //www, stlport . org/| 
resources/ StepanovUSA . html 

[74] J. Siek and J. Widman. Proposed wording for scoped concept maps. Technical Report 
N2414, ISO/IEC JTC 1 SC22 WG21, September 2007. 

[75] J. G. Siek. A Language for Generic Programming. PhD thesis, Indiana University, August 
2005. 

[76] J. G. Siek. Scoped concept maps. Technical Report N2098, ISO/IEC JTC 1 SC22 WG21, 
September 2006. 

[77] J. G. Siek and A. Lumsdaine. The Matrix Template Library: Generic components for high- 
performance scientific computing. Computing in Science and Engineering, l(6):70-78, 
Nov/Dec 1999. ISSN 1521-9615. 

[78] J. G. Siek and A. Lumsdaine. Advances in Software Tools for Scientific Computing, chapter 
A Modern Framework for Portable High Performance Numerical Linear Algebra. Springer, 
2000. 

[79] J. G. Siek and A. Lumsdaine. Concept checking: Binding parametric polymorphism in 
C++. In Proceedings of the First Workshop on C++ Template Programming, Erfurt, Ger- 
many, 2000. 

[80] J. G. Siek and A. Lumsdaine. Essential language support for generic programming: For- 
malization part 1. Technical Report 605, Indiana University, December 2004. 

[81] J. G. Siek and A. Lumsdaine. Essential language support for generic programming. In 
PLDI '05: Proceedings of the ACM SIGPLAN 2005 Conference on Programming Language 
Design and Implementation, pages 73-84. ACM Press, June 2005. ISBN 1-59593-056-6. 

[82] J. G. Siek and A. Lumsdaine. Language requirements for large-scale generic libraries. In 
GPCE '05: Proceedings of the 4th International Conference on Generative Programming 
and Component Engineering, September 2005. 

[83] J. G. Siek and A. Lumsdaine. A language for generic programming in the large. Science of 
Computer Programming, 76:423-465, September 201 1. 

[84] J. G. Siek, L.-Q. Lee, and A. Lumsdaine. The Boost Graph Library: User Guide and 
Reference Manual. Addison-Wesley, 2002. 

[85] J. G. Siek, D. Gregor, R. Garcia, J. Willcock, J. Jarvi, and A. Lumsdaine. Concepts for 
C++0x. Technical Report N1758=05-0018, ISO/IEC JTC 1, Information Technology, Sub- 
committee SC 22, Programming Language C++, January 2005. 



49 



[86] A. A. Stepanov. Design of generic libraries. Lecture given at SRI, 1991. 



[87] A. A. Stepanov and M. Lee. The Standard Template Library. Technical Report X3J16/94- 
0095, WG21/N0482, ISO Programming Language C++ Project, May 1994. 



[88] A. Stevens. Al Stevens interviews alex stepanov. Dr. Dobb's, March 1995. URL http : 
|/ / www . sgi . com/ tech/ stl/ drdobbs-interview . html[ 

[89] B. Stroustrup. What is object-oriented programming? IEEE Softw., 5:10-20, May 
1988. ISSN 0740-7459. doi: 10.1109/52.2020. URL |http : / /portal . acm. orq/| 
lcitation.cfm?id=62 4 5 69 . 62 4 72T1 

[90] B. Stroustrup. Parameterized types for C++. In USENIX C++ Conference, October 1988. 

[91] B. Stroustrup. In The second ACM SIGPLAN conference on History of programming lan- 
guages, HOPL-II, pages 271-297, New York, NY, USA, 1993. ACM. ISBN 0-89791-570- 



4. doi: http://doi.acm.org/10.1145/154766.155375. URL |http : //doi . acm. org/10 . 
11145/154766. 1553751 

[92] B. Stroustrup. Concepts - a more abstract complement to type checking. Technical Report 
N1510=03-0093, ISO/IEC JTC 1, Information Technology, Subcommittee SC22, Program- 
ming Language C++, Oct. 2003. [http : / /www, open-std. org/ jtcl/sc22/wg21| 

[93] B. Stroustrup. Evolving a language in and for the real world: C++ 1991-2006. In Pro- 
ceedings of the third ACM SIGPLAN conference on History of programming languages, 
HOPL III, pages 4-1-4-59, New York, NY, USA, 2007. ACM. ISBN 978-1-59593-766-7. 
doi: http://doi.acm.org/10.1145/1238844.1238848. URL |http : //doi . acm. org/10 . | 
11145/1238844 . 1238848| 

[94] B. Stroustrup. Simplifying the use of concepts. Technical Report N2906, ISO/IEC JTC 1 
SC22WG21, June 2009. 

[95] B. Stroustrup and G. Dos Reis. Concepts - design choices for template argument checking. 
Technical Report N1522, ISO/IEC JTC 1 SC22 WG21, 2003. 

[96] B. Stroustrup and G. Dos Reis. Concepts - syntax and composition. Technical Report 
N1536, ISO/IEC JTC 1 SC22 WG21, 2003. 

[97] B. Stroustrup and G. Dos Reis. A concept design (rev. 1). Technical Report N1782=05- 
0042, ISO/IEC JTC 1, Information Technology, Subcommittee SC 22, Programming Lan- 
guage C++, May 2005. 

[98] M. Tasker. The long pole gets longer. Technical Report N2893, ISO/IEC JTC 1 SC22 
WG21, June 2009. 

[99] M. Torgersen. Virtual types are statically safe. In FOOL 5: The 5th International Workshop 
on Foundations of Object-Oriented Languages, January 1998. 



50 



[100] B. L. van der Waerden. Algebra: Volume I. Springer, 1991. 

[101] T. Veldhuizen. Using C++ template metaprograms. C++ Report, 7(4):36^13, May 1995. 
ISSN 1040-6042. Reprinted in C++ Gems, ed. Stanley Lippman. 

[102] P. Wadler and S. Blott. How to make ad-hoc polymorphism less ad hoc. In POPL '89: 
Proceedings of the 16th ACM SIGPLAN-SIGACT symposium on Principles of programming 
languages, pages 60-76, New York, NY, USA, 1989. ACM Press. ISBN 0-89791-294-2. 

[103] M. Wenzel. Using Axiomatic Type Classes in Isabelle. TU Miinchen, October 2005. 

[104] D. Yu, A. Kennedy, and S. Don. Formalization of generics for the .net common language 
runtime. In Proceedings of the 31st ACM SIGPLAN-SIGACT symposium on Principles 
of programming languages, POPL '04, pages 39-51, New York, NY, USA, 2004. ACM. 
ISBN 1-581 13-729-X. doi: http://doi.acm.org/10.1145/964001.964005. URL |http:771 
[doT". acm.org/ 10 .1145/964001. 9 64 005[ 



51 



